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Massachusetts  Computer  Associates,  Inc.  (COMPASS)  is  pleased  to 
submit  this  Final  Technical  Report  for  Contract  DAAK80-81-C-0072, 
on  Formal  Techniques  for  Specification  and  Validation  of  Tactical 
Systems. 

The  primary  results  of  this  basic  research  program  are  embodied  in  a 
published  paper,  “Object-Oriented  Subsystem  Specification”,  which 
is  attached  as  Appendix  I. 

A  major  objective  of  this  research  was  to  initiate  a  transfer  of  formal 
specification  technology  into  the  design  and  development  of  tactical 
systems.  To  this  end,  the  research  was  carried  out  in  collaboration 
with  engineers  from  CENTACS,  who  participated  in  a  number  of 
experimental  case  studies  over  the  duration  of  the  project.  One  of 
these  was  documented  in  a  separate  paper,  attached  as  Appendix  II; 
this  describes  our  collective  first  attempts  to  formalize  the  design  for  a 
(hypothetical)  “tactical  situation  -  reporting  system”,  before  either  the 
formal  specification  techniques  or  our  informal  conception  of  that 
system  had  fully  matured.  Essentially  the  same  example  is  considered 
in  the  final  paper. 

The  starting  point  for  this  reasearch  was  the  mathematical  approach  to 
system  specification  originated  by  J.  R.  Abrial  at  Oxford  University, 
which  has  come  to  be  known  as  “Z".  Much  of  the  work  on  this 
contract  was  carried  out  in  direct  collabortion  with  the  Programming 
Research  Group  at  Oxford.  A  collection  of  papers  on  Z  from  this 
group,  reflecting  the  state  of  their  work  at  that  stage,  is  attached  as 
Appendix  HI. 
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OBJECT-ORIENTED  SUBSYSTEM  SPECIFICATION 


S.A.  Schuman  * 
University  of  East  Anglia 


D.H.  Pitt  t 
University  of  Surrey 


I.  Introduction 

The  aim  of  this  paper  is  to  introduce  a  rigorous,  mathematically  based  notation  for  supporting  the 
earliest  phases  of  the  software  design  process,  sometimes  referred  to  as  "systems  architecture". 
Our  objective  is  the  development  of  a  formal  framework  that  could  be  applied  successfully  in 
practice.  As  such,  we  are  consciously  following  in  the  footsteps  of  VDM  [Bjomer  &  Jones, 
1978]  and  [Jones,  1980].  The  particular  technique  presented  here  is  a  variant  on  the  approach 
originated  at  Oxford  by  J-R.  Abrial,  which  has  come  to  be  known  as  "Z";  this  is  now  documented 
in  [Suffrin  etaL,  1985]  and  [Hayes,  1986], 

Underlying  much  of  the  current  work  in  this  area  is  the  well  established  structuring  principle  of 
data  abstraction ,  which  implies  some  basis  for  modular  decomposition  into  separately  specifiable 
sub-units.  Over  the  years,  two  somewhat  distinct  "schools  of  thought"  have  emerged  as  to  the 
proper  basis  for  applying  such  principles  "in  the  large".  We  *rgue  that  this  apparent  divergence 
reflects  a  fundamental  (technical)  distinction,  between  values  as  opposed  to  objects.  Quite 
obviously,  both  concepts  have  an  important  idle  to  play. 

In  the  case  of  values  this  decomposition  is  based  upon  "abstract  data  types",  which  serve  to 
characterise  some  domain  of  interest  in  terms  of  certain  constructor  and  selector  functions.  The 
abstraction  then  involves  specifying  an  equality  relation  over  such  (immutable)  values.  The  so- 
called  "algebraic"  approach,  initiate!  by  [Guttag  &  Homing,  1978]  and  [Goguen  et  al.,  1978]  is 
therefore  especially  appropriate  in  this  context;  it  is  also  the  focus  of  most  recent  research  on 
formal  specification  methods. 

A  "class"  of  abstract  objects,  in  contrast  to  a  "type"  of  values,  serves  to  encapsulate  the  definition 
of  some  internal  state  in  conjunction  with  an  associated  set  of  access  operations  for  querying 
and/or  updating  any  individual  instance  of  that  class.  Thus  "axiomatic"  methods  involving  pre- 
and  postconditions,  expressed  in  terms  of  a  suitable  state  model,  would  appear  to  be  the  most 
natural  approach  for  specifying  such  abstractions.  As  foreshadowed  by  [Dahl,  1972]  and  [Hoare, 
1972],  the  "object-oriented"  paradigm  originally  embodied  in  SIMULA  67  (and  subsequently 
incorporated  into  a  number  of  more  recent  programming  languages)  has  proved  to  be  an  extremely 
effective  technique  for  decomposing  and  reasoning  about  complex  systems.  Our  goal  here  is  to 
provide  a  useful  counterpart  to  those  facilities  at  the  level  of  formal  specifications. 

Section  2  of  this  paper  contains  an  informal  overview  of  our  notations  and  conventions.  Section  3 
gives  a  more  formal  treatment,  including  rules  of  inference  for  reasoning  about  the  behaviour 
implied  by  such  specifications.  Section  4  concludes  with  the  development  of  an  extended 
example,  specifying  the  architecture  of  a  distributed  information  system. 
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2.  Notations  and  Conventions 

Structurally,  the  specification  of  an  object  class  comprises  two  distinct  kinds  of  definition,  viz. 
(i)  A  single  state  schema,  which  has  the  following  general  form: 


r(7t! . Jtk) 


(ii)  An  associated  set  of  event  schema,  each  of  which  is  formed  as  follows: 


■'•4>i(ai . Ctm-^ . Pn)  _ 

P  —  parameter  declarations 


Q  —  precondition  predicates 


R  —  postcondition  predicates 


The  header  of  a  state  schema  identifies  the  class  in  question  (i.e.  it  gives  it  a  name),  as  well  as 
naming  any  formal  parameters  for  that  class.  The  event  schema  headers  introduce  the  name  of 
each  separate  operation,  in  conjunction  with  names  for  any  input  and/or  output  parameters  figuring 

in  its  signature.  The  association  alluded  to  above  is  indicated  by  simply  prefixing  the  class  name  T 

to  the  individual  operation  names  <J>i  ...  <t>p,  which  are  for  the  moment  assumed  to  be  unique  in  the 
context  of  a  given  specification.  No  provisions  for  explicitly  grouping  such  schema  texts  into 
larger  "modules"  are  considered  here. 

Inside  a  schema  definition  the  different  lists  of  declarations  or  predicates  are  normally  set  out 
vertically,  as  independent  items  appearing  one  under  another,  wherein  the  order  is  not  significant; 
alternatively,  several  such  items  may  be  written  on  the  same  line,  separated  by  semicolons.  It 
often  arises  that  a  particular  list  is  empty,  whereupon  the  corresponding  part  of  the  schema  may  be 
omitted  entirely.  These  latter  conventions  will  be  illustrated  by  a  succession  of  examples,  to 
follow. 

This  "box-like"  presentation  of  schema  definitions  was  adopted  mainly  as  a  means  for  setting  off 
the  enclosed  formal  text  from  its  surrounding  (natural  language)  explanations  -  without  which  a 
specification  is  neither  complete  nor  comprehensible.  Within  this  minimal  and  strictly  syntactic 
framework,  the  actual  content  of  every  such  specification  is  expressed  using  essentially  the 
traditional  notations  of  predicate  calculus  and  classical  (ZF)  set  theory,  extended  as  and  when 
necessary  by  additional  constructs  defined  in  terms  of  those  notations.  Although  we  are  assuming 
one  specific  development  of  that  underlying  formalism  [Abrial  1982],  any  other  axiomatic 
formulation  of  this  well  understood  mathematical  basis  would  in  principle  be  equally  appropriate. 


Whilst  we  intend  that  these  specifications  should  have  a  fully  rigorous  (and  therefore  formal) 
interpretation,  it  is  perfectly  acceptable  -  and  usually  quite  helpful  -  to  start  out  with  a  much  more 
"operational"  perspective.  The  state  schema,  which  is  where  one  begins  in  order  to  specify  some 
class  of  interest,  might  well  be  viewed  as  defining  an  abstract  "data  model"  for  all  objects 
belonging  to  that  class.  Support  for  abstraction  comes  firstly  from  the  fact  that  this  model  is 
expressed  in  terms  of  a  "very  high-level"  and  purely  "declarative"  language,  in  which  the  "data 
types"  correspond  to  (presumably  familiar)  mathematical  constructions  as  opposed  to  the  more 
concrete  structures  normally  provided  by  a  programming  language.  Any  formal  parameters  of  the 
state  schema  stand  for  constant  components,  the  values  of  which  are  independently  fixed  for  each 
separate  object  instance.  The  remaining  components  declared  within  that  schema  may  then  be 
construed  as  "state  variables"  of  an  individual  object,  in  that  their  values  can  be  selectively  modified 
as  a  consequence  of  applying  particular  operations.  The  invariant  predicates  assert  that  certain 
relationships  amongst  the  component  values  must  always  hold;  as  such,  they  serve  to  impose 
constraints  upon  how  the  state  of  an  object  may  be  changed  by  any  associated  operation.  Finally, 
the  initialisation  predicates  establish  whatever  conditions  are  to  be  assumed  at  the  outset,  when  an 
object  of  the  class  in  question  is  first  instantiated. 

The  requisite  operations  arc  then  specified  with  respect  to  this  abstract  model.  Each  such  definition 
is  presented  as  a  free-standing  event  schema  (analogous  to  an  independent  function  or  procedure), 
but  expressed  as  if  it  were  textually  "embedded"  into  the  scope  of  the  corresponding  state  schema: 


r.«fo(...  -*  ■••) 


Thus  all  component  names  appearing  therein  refer  to  the  current  values  of  some  representative 
instance;  the  actual  object  will  be  designated  whenever  this  operation  is  subsequently  applied. 
Names  figuring  in  its  signature  denote  additional  constants,  standing  for  the  values  which  are  either 
input  (as  arguments)  or  output  (as  results)  in  the  context  of  any  given  application.  In  general,  the 
precondition  predicates  will  range  over  both  component  and  parameter  names.  They  thereby  serve 
not  only  to  restrict  applicability  of  the  operation  to  certain  object  states  but  also  to  constrain  the 
possible  argument  and  result  values  relative  to  those  states:  such  an  event  may  occur  if  and  only  if 
all  of  these  conditions  are  satisfied  simultaneously. 

Explicit  effects  of  this  event  (upon  individual  state  variables)  are  established  by  the  postcondition 
predicates,  wherein  we  adopt  the  common  convention  of  "dashing"  (or  "priming")  a  component 
name  to  denote  its  value  after  the  event;  for  symmetry,  the  same  convention  is  used  in  the 
initialisation  predicates  of  the  state  schema,  where  a  dashed  name  stands  for  the  initial  value  of  that 
component  (after  instantiation). 
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About  the  simplest  possible  example  is  that  of  a  running  balance,  which  may  increase  or  decrease 
by  some  arbitrary  but  observable  amount.  Such  balances  can  be  modelled  by  a  single  state 
component,  corresponding  to  their  current  value: 


B 


For  purposes  of  illustration  this  value  is  specified  in  terms  of  natural  numbers  rather  than,  say, 
integers  (or  some  more  specialised  unit  of  account).  Thus  there  is  no  a  priori  upper  bound  on  any 
balance,  but  "overdrafts"  are  precluded.  As  the  invariant  is  empty,  no  further  constraints  are 
imposed.  Within  this  domain,  the  initial  value  of  every  balance  is  zero.  The  operations  of  interest, 
namely  increasing  or  decreasing  a  balance,  may  then  be  defined  quite  succinctly: 


B.l _ 


No  precondition  is  needed  for  the  increase  operation.  In  the  case  of  a  decrease  operation, 
however,  the  desired  postcondition  cannot  be  established  consistently  without  requiring  a  non¬ 
zero  balance  before  the  event  (since  there  is  no  natural  number  b'  <  0  unless  b  >  0). 

Occurrences  of  these  events  are  only  observable  in  the  sense  that  an  increase  always  results  in  a 
new  balance  which  is  strictly  greater  than  it  was  beforehand,  whereas  a  decrease  has  the  opposite 
effect.  But  the  amount  by  which  the  balance  changes  in  each  instance  is  (deliberately)  left 
indeterminate,  so  there  is  no  means  of  influencing  what  choice  is  made  on  any  given  occurrence. 
An  operation  to  query  the  current  balance  (without  changing  its  value)  might  also  be  provided,  if 
only  to  avoid  the  pitfalls  of  inadvertently  attempting  to  decrease  a  balance  that  has  gone  to  zero: 


B.Q  (->  a ) 


This  operation  has  no  effect  (as  indicated  by  the  absence  of  any  postconditions),  and  is  always 
applicable.  But  the  only  reason  for  defining  such  events  would  be  to  encapsulate  completely  the 
abstract  model  in  question.  It  is  often  more  productive  to  defer  these  considerations  until  later 
stages  in  the  specification  process,  when  the  contextual  requirements  have  been  firmly  established. 
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The  dynamic  behaviour  characterised  by  such  specifications  is  most  easily  visualised  in  the  form  of 
a  "decision  tree".  Accordingly,  the  initial  pattern  for  a  balance  belonging  to  the  class  specified 
above  (ignoring  the  superfluous  query  function)  might  be  depicted  as  follows: 


The  branches  of  this  tree  are  labelled  by  (denotations  of)  alternative  events  which  may  occur  at 
distinct  points  in  any  possible  history  and  those  points,  the  nodes,  are  annotated  with  predicates 
reflecting  the  postcondition  established  by  the  immediately  preceding  operation;  the  root  annotation 
corresponds  to  the  initialisation  predicate  in  the  state  schema.  Within  these  annotations, 
component  names  are  subscripted  so  as  to  differentiate  successive  points  in  "time"  (indicated  as 
depth  in  the  tree).  A  particular  history  is  then  given  by  the  sequence  of  events,  or  trace,  along  some 
path  from  the  root  of  such  a  tree  to  any  reachable  node.  The  predicates  associated  with  each 
successive  node  in  that  history  are  to  be  interpreted  as  incremental  (or  cumulative)  assertions  about 
the  object  state  up  to  that  point. 

At  the  first  step  in  the  behaviour  for  this  class,  the  only  possible  event  is  the  increase  operation  I, 
which  follows  directly  from  the  initial  condition  for  the  class  B  and  the  precondition  of  the  decrease 
operation  D.  Thereafter  either  I  or  D  events  may  in  general  occur,  and  indeed  an  increase  is  always 
possible.  If,  however,  the  most  recent  event  in  any  trace  was  a  decrease  operation,  then  the 
admissibility  of  another  D  event  at  that  point  becomes  indeterminate  because  its  precondition  may 
or  may  not  be  satisfied,  depending  on  how  this  specification  is  subsequently  refined  (or 
implemented).  Indeterminacy  of  this  sort  is  shown  above  as  a  dotted  branch,  to  suggest  that  the 
ensuing  subtree  is  conditionally  present;  the  labels  appearing  on  such  branches  include  an 
antecedent  as  part  of  the  event  denotation,  which  predicates  are  obtained  directly  from  the 
corresponding  precondition. 

The  sole  purpose  of  this  (admittedly  artificial)  exercise  in  underspecification  was  to  defer  all 
commitments  that  would  in  any  way  quantify  the  actual  increase  or  decrease  to  a  running  balance  - 
so  as  to  encompass  the  broadest  possible  class  of  potential  refinements.  These  include  subclasses 
for  which  this  indeterminate  behaviour  is  fully  resolved  (that  is,  where  every  "conditional  branch" 
in  the  original  history  is  either  provably  admissible  or,  alternatively,  ruled  out  altogether),  as  well 
as  ones  wherein  the  indeterminacy  is  still  present  (but  dependent  upon  more  specific  conditions, 
which  are  only  meaningful  in  the  context  of  that  particular  subclass). 


As  a  general  rule,  refining  the  specification  of  some  class  T  involves  introducing  a  new  subclass  A, 
for  which  further  properties  are  specified  relative  to  that  given  base.  The  definition  of  such  a 
subclass  takes  the  form  of  a  state  schema  which  simply  identifies  the  relevant  base  definition(s). 

The  actual  extensions  are  then  presented  within  an  embedded  subschema: 


A(. . 

) 

n...);  ... 

—  components  of  A 

D 

--  invariants  of  A 

--  initialisation  of  A 

This  refinement  may  be  understood  to  stand  for  a  textual  expansion  of  the  definition  as  written 
(wherein  the  nesting  structure  is  preserved): 

A(...) - 


Zr 


initialisation  of  T 


Operations  associated  with  the  new  subclass  would  normally  be  defined  in  terms  of  existing 
operations  on  the  base  class(es).  Such  promotions  can  be  specified  in  an  analogous  fashion,  as 
refinements  to  the  corresponding  event  schema: 

A.<l>j  (. . .  — »  ... ) _ 

r.<t>i  (...  — > ...);  ... 

Pj  --  parameters  of  <{>j 

Qj  —  preconditions  of  <j)j 

Rj  --  postconditions  of  <J)j 

Again,  the  intended  interpretation  is  most  easily  visualised  in  terms  of  its  textual  expansion: 

A.<t>j  _ 

P\  —  parameters  of  <|>j 
Q\  —  invariants  of  <|)j 


Pj  —  parameters  of  <>j 


Observe  that  all  parameter  declarations  and  invariants  for  a  designated  base  operation  <hj  are 
effectively  "inherited"  within  this  definition;  thus,  only  additional  parameters  or  constraints 
associated  with  the  new  operation  need  to  be  specified  explicitly.  This  applies  equally  to  the 
context  of  postconditions. 

As  suggested  by  the  ellipses  above,  our  conventions  allow  for  so-called  "multiple  inheritance", 
where  more  than  one  base  may  be  identified  in  conjunction  with  such  refinements.  This  provides  a 
means  for  combining  several  (compatible)  definitions  at  the  same  level,  and  thereby  specifies  a 
subclass  which  belongs  to  many  different  classes  all  ?t  once. 


An  obvious  refinement  of  the  previously  specified  balances  is  the  subclass  of  counters,  for  which 
the  abstract  model  is  identical  (whence  the  state  schema  is  in  effect  just  a  renaming  of  that  class). 
The  operations  for  incrementing  or  decrementing  such  a  counter  could  then  be  expressed  as 
promotions  of  the  corresponding  increase  and  decrease  events,  but  with  stronger  postconditions: 


b'=  b  +  1 


Both  the  initial  conditions  for  this  new  subclass  as  well  as  the  necessary  precondition  for  the 
decrement  operation  are  thereby  inherited,  as  can  be  seen  by  expanding  its  specification  in  full: 


b:  NAT 


b'  >  b 


b'  =  0 


b1  =  b  +  1 


b'<b 


b'  =  b  - 1 


It  emerges  that  the  weaker  "observability"  postconditions  of  the  balance  operations  are  also 
inherited.  These  properties  would  be  (trivial)  theorems  of  the  event  definitions  if  such  counters 
had  instead  been  specified  directly,  without  reference  to  the  class  of  balances: 


b:  NAT 


b'  =  b  +  1 


b’=  0 


DC.D 


b'  =  b  - 1 


This  example  is  of  course  so  simple  that  it  hardly  matters  which  way  one  expresses  the 
specification.  The  behaviour  is  the  same  in  both  cases: 


b0  =  0 


Not  surprisingly,  the  increment  and  decrement  operations  on  counters  correspond  respectively  to 
the  successor  and  predecessor  functions  on  natural  numbers  -  which  is  precisely  what  was 
specified!  (The  backward-pointing  edges  above,  indicating  that  the  nodes  in  question  may  be 
equated  on  the  basis  of  their  associated  predicates,  suggest  various  recursive  formulations  for  these 
functions.) 

It  should  be  observed  that  this  counter  behaviour  is  in  fact  a  fully  resolved  (albeit  still  unbounded) 
refinement  of  the  balance  behaviour  specified  at  the  outset,  since  the  more  restrictive  postconditions 
now  determine  whether  a  decrement  event  is  or  is  not  admissible  at  every  point. 


Should  one  subsequently  wish  to  impose  an  upper  bound  upon  such  counters,  this  could  be 
specified  as  a  further  refinement  of  the  unbounded  class,  corresponding  to  a  restriction  on  the 
original  (balance)  model.  The  increment  operation  then  requires  a  precondition,  so  as  to  preserve 
this  new  invariant,  whereas  the  decrement  operation  is  just  a  direct  promotion: 


BC.D 


Alternatively,  this  might  have  been  approached  by  first  specifying  a  subclass  of  bounded  balances: 

BB  (m) _ 

B 

m:  NAT  >  0 
b£m 

BB.D - 

B.D 

This  new  basis  can  then  be  refined,  as  before,  by  adding  the  postconditions  specific  to  counters: 


With  either  approach  the  resultant  behaviour  is  indeed  bounded,  but  not  fully  resolved  -  in  that  the 
admissibility  of  an  increment  operation  now  depends  upon  the  value  of  the  formal  parameter  m, 
which  may  be  different  for  each  separate  instantiation  of  both  BC  and  CB. 
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Another  interesting  subclass  of  running  balances  is  the  more  traditional  notion  of  an  account  that 
may  be  credited  or  debited  by  some  specific  amount,  which  is  supplied  as  an  argument  each  time 
one  of  these  operations  is  invoked.  Such  accounts  could  also  be  specified  by  refinement: 


B 


A.C  (a). 
B.l 


a:  NAT  >  0 


b’  =  b  +  a 


A.D  (a). 


B.D 


a:  NAT[1..b] 


b’  =  b  -  a 


The  amount  to  be  credited  or  debited  must  be  non-zero  in  every  case,  in  order  to  satisfy  the 
observability  properties  imposed  in  the  context  of  balances;  moreover,  the  amount  of  a  debit  must 
not  exceed  the  current  balance  since  overdrafts  were  ruled  out  from  the  beginning.  Thus  the 
admissibility  of  a  credit  or  debit  operation  is  always  indeterminate,  in  that  it  depends  upon  the  actual 
value  of  an  input  parameter. 


Refinement  of  a  class  specification  more  typically  involves  proper  extension,  in  the  sense  of  adding 
new  components  to  the  underlying  model  (some  of  which  may  be  wholly  or  partially  redundant). 
This  corresponds  to  specifying  additional  "attributes"  for  a  given  subsystem,  possibly  (but  not 
necessarily)  associated  with  its  implementation.  But  such  extensions  might  also  be  introduced 
solely  to  reason  about  the  implied  behaviour.  Suppose,  for  example,  that  one  wished  to  establish 
that  the  sum  of  all  debits  to  an  account  never  exceeds  the  total  of  actual  credits.  A  subclass  of 
audited  accounts  is  probably  more  appropriate  for  these  purposes: 


AA. 


AA.C  (a) 


c.d:  NAT 


A.C  (a) 


c’  =  c  +  a 


b  =  c-d 


AA.D  (a) , 


A.D  (a) 


d’  =  d  +  a 
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3.  Reasoning  About  Specifications 


In  this  section,  we  outline  the  formal  basis  for  reasoning  about  subsystem  specifications,  both 
statically  (considering  only  the  individual  schema  comprising  a  class  definition)  and  dynamically 
(over  their  implied  behaviour);  in  particular,  we  develop  the  special  rules  of  "historical"  inference 
which  underlie  our  conventions. 


For  these  purposes  we  shall  also  introduce  another  simple  but  much  more  typical  example,  dealing 
with  an  issue  that  arises  in  the  design  of  a  great  many  systems,  viz.  unique  identification.  The  class 
of  interest  therefore  corresponds  to  a  "generator"  for  the  requisite  "reference"  values,  which  may 
well  be  abstracted  merely  as  elements  drawn  from  some  entirely  arbitrary  "carrier  set",  say  R.  The 
state  of  such  a  generator  would  then  be  modelled  as  a  (finite)  subset  R  of  this  given  carrier  set, 
comprising  the  references  outstanding  at  any  point,  where  R  is  initially  empty.  Generation  of  a 
new  reference  is  then  some  (indeterminate)  selection  from  the  complement  of  R  (i.e.  RvR,  where  \ 
denotes  set  difference),  whilst  nullifying  (or  "freeing")  a  reference  is  just  its  deletion  from  R: 


REF.  New(- 


R:  set[R] 


r:  ~  R 


R'  =  0 


r  e  R’ 


REF.  Null(r) 


Taking  R  as  NAT>0  (and  showing  other  choices  as  "fan-outs"),  the  initial  behaviour  includes: 


R0  =  0 


New(-»  1 ) 


1  6  Ri 


Null(1) 


New(->  2) 


1  <E  R2 


2  e  R2 


Null(1) 


New(->  3) 


New(->  1) 


Null(2) 


1  e  R3 


1  g  Rg 


2  €  R3 


3  e  R3 


•  ^  - 


The  most  common  application  of  such  references  is  to  identify  (or  "index")  occurrences  of  values 
belonging  to  some  other  set,  say  S.  This  sort  of  association  is  normally  modelled  as  a  finite  map 
(i.e.  a  partial  function): 


It  would  perhaps  be  more  natural  to  specify  this  association  directly  as  a  new  subclass  of  REF: 


(Note  that  the  map  is  now  specified  as  a  total  function).  This  may  be  further  refined  by  requiring 
that  the  association  be  injective  (one-to-one),  which  is  expressed  by  asserting  that  its  converse  is 
also  functional: 

INJ _  INJ.  New(s  ->  r) _ 


I  =  M'1 


INJ.  Nuil(r) 


»r 


Taking  S  to  be  strings  (as  in  a  "symbol  table"),  the  initial  behaviour  of  this  subclass  now  includes: 


Rn=0 


New(‘abc’  1) 


M1(1)  =  ‘abc* 


Null(1) 


New(‘ijk’  ->  2) 


1  fit  Rp 


M2(2)  =  ‘ijk* 


New(‘xyz’  -»  1 ) 


Null(1) 


Null(2) 


M3(1)  =  ‘xyz’ 


1  <5  R3 


2«  R3 


New('xyz’  3) 


M3(3)  =  ‘xyz’ 


Such  behaviours  arc  to  be  modelled  in  terms  of  traces  of  event  denotations  (the  sequence  of  labels 
along  any  possible  path  in  the  decision  tree  depicted  above),  where  every  trace  is  associated  to  a 
corresponding  history  (predicates  on  the  state,  as  suggested  by  the  node  annotations)  from  which 
properties  holding  "at  that  point"  may  then  be  inferred. 

The  different  forms  of  schema  definition  making  up  a  class  specification  are  nothing  more  than  a 
highly  stylised  framework  for  setting  out  the  various  predicates  entering  into  any  possible  history. 
The  predicates  in  question  range  over  (mathematical)  variables  which  are  introduced  by  a  list  of 
declarations,  as  follows: 

v,:  7,;  v,,:  Tq 

wherein  vf ...  vq  arc  just  the  names  of  these  variables  and  7/  ...  Tq  stand  for  their  corresponding 
set-theoretic  "types".  Such  types  are  expressed  in  terms  of  certain  given  or  "generic"  set  names 
(herein  denoted  by  letters  from  a  distinguished  alphabet  A ...  Z),  the  names  of  externally  defined 
types  (e.g.  NAT)  and  the  usual  set  constructions  over  such  types  -  including  products,  partial  or 
total  functions  and  relations,  finite  subsets  and  sequences  etc.  Inside  a  schema  definition,  each 
variable  so  declared  is  thereby  asserted  to  belong  to  some  set  having  the  particular  structural 
properties  associated  with  its  specified  type.  Thus  these  assertions  can  be  embodied  into  a  set  of 
predicates  having  the  following  form: 

e7,,  ...,vqsrj 


where  Vf...Vp  are  just  free  variables  within  that  definition.  As  such,  they  may  be  implicitly 
quantified  at  die  level  of  the  schema  as  a  whole;  embedded  declarations  could  then  be  thought  of  as 
corresponding  to  nested  quantification. 

The  characteristic  predicates  for  a  given  schema  are  derived  by  combining  these  conditions  with 
additional  predicates  (over  the  same  free  variables)  which  are  obtained  from  other  parts  of  that 
schema  definition.  All  such  derived  sets  stand  for  the  conjunction  of  their  constituent  predicates 
(whence  the  empty  set  is  logically  equivalent  to  true). 


V  V,‘*v  V 


Two  separate  sets  of  predicates  arc  derived  from  the  state  schema  for  a  particular  class,  as  follows: 

-  the  state  predicates  S  =  Xu  Y 

(where  X  is  obtained  from  the  component  declarations  and  Y from  the  state  invariants); 

-  the  initial  predicates  /  =  SuZ 

(where  S  is  the  state,  given  above,  and  Zis  obtained  from  the  initialisation  predicates). 

The  state  predicates  are  undashed,  in  that  none  of  the  free  variables  occurring  therein  are  dashed. 
But  the  initial  predicates  are  mixed,  which  is  to  say  that  they  will  in  general  contain  both  dashed  and 
undashed  variables.  This  is  because  initialisation  is  specified  as  a  "pseudo-event"  (and  will 
therefore  be  discussed  in  that  context,  below). 

Definition.  A  model  for  the  state  as  specified  in  the  state  schema  for  a  given  class  is  some 
association  of  actual  sets  to  the  generic  names  appearing  (directly  or  indirectly)  within  those 
declarations,  together  with  any  substitution  of  values  from  those  sets  (or  constructed  sets)  for  all 
free  variables  within  that  model. 

The  state  so  specified  must  be  consistent  in  the  usual  sense:  there  is  such  a  model,  and  values  for 
the  state  variables  within  that  model,  satisfying  all  of  the  predicates  in  S  (i.e.  both  types  and 
invariants);  otherwise,  that  specification  is  contradictory  and  no  such  class  exists. 

The  operations  specifically  associated  with  a  given  class  are  expressed  as  relations  between 
undashed  and  dashed  names,  standing  respectively  for  the  value  of  a  state  variable  before  and  after 
some  occurrence  of  the  event  in  question.  This  convention  implies  a  wholly  independent  set  of  free 

variables  v/, ....  vQ’  which  have  exactly  the  same  declarations  as  their  undashed  counterparts.  The 
corresponding  types  and  invariants,  denoted  S',  are  therefore  obtained  by  simply  dashing  each 
such  undashed  name  occurring  free  within  S.  The  characteristic  predicates  for  each  event  4>j  are 
then  derived  from  its  schema  definition  as  follows: 

-  the  guard  predicates  G  -  S  U  (P  U  O) 

(which  incorporates  the  parameter  declarations  Pand  the  preconditions  Q); 

-  the  final  predicates  F-  S'  U  R 

(which  introduces  the  dashed  names  in  conjunction  with  the  postconditions  R ); 

-  the  event  predicates  E  =  G  U  F 

(which  thereby  relates  the  state  values  before  and  after  any  occurrence  of  that  event). 

Each  associated  event  must  also  be  consistent  in  its  own  right,  meaning  that  there  is  a  model 
(obtained  in  the  same  way  as  for  a  state)  satisfying  all  of  the  predicates  in  E  The  same  applies  to 
any  specified  initialisation,  characterised  by  the  set  /  as  defined  above.  We  shall  speak  of  these 
characteristic  sets  as  standing  for  what  they  serve  to  describe:  "a  state  S  ",  "a  guarded  state  G  ",  "a 
final  state  F”,  "an  event  E  "  etc.  The  consistency  requirement  on  all  such  predicates  is  essentially 
static,  in  that  it  can  be  established  for  each  separate  schema  in  isolation  using  only  axioms  of  the 
underlying  set  theory  and  classical  rules  of  inference. 

Implicit  in  every  event  is  some  "admissibility"  condition,  under  which  it  is  allowed  to  occur  at  all; 
this  is  given  by  simply  positing  the  existence  of  a  cotresponding  final  state. 

Definition.  Let  E  be  an  event;  then  its  implied  precondition,  denoted  ipc(E),  is  obtained  by 
existentially  quantifying  over  all  dashed  variable  names  occurring  free  within  E.  The.  event  E  is 
admissible  (and  may  therefore  occur )  in  any  current  state  C  which  is  consistent  with  ipc(E). 

It  follows  by  construction  that  ipc(E)  =>  G  =>  (P  a  Q  a  S),  where  G  is  the  guarded  state  embodied 
in  E;  hence  that  event  may  only  occur  if  its  parameter  declarations  P  and  explicit  preconditions Q 
(as  well  as  the  underlying  state  invariants  S )  are  satisfied. 
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It  is  desirable,  however,  that  a  given  event  can  indeed  occur  (i.e."complete"  successfully) 
whenever  its  preconditions  are  satisfied,  meaning  that  there  must  be  a  consistent  final  state  for  all 
admissible  occurrences.  This  leads  us  to  impose  a  much  stronger  consistency  requirement 

Definition.  Let  W  be  a  set  of  predicates,  and  V  be  the  subset  of  undashed  predicates  within  W\ 
then  W  is  end-consistent  iff  V  is  consistent  and,  for  any  current  state  in  any  model  that  satisfies  all 
the  predicates  in  V,  there  is  a  corresponding  final  state  which  satisfies  all  predicates  in  W\V. 

Consider,  for  example,  some  predicates  over  a  state  variable  N,  assumed  to  be  of  type  set  [NAT]: 

(i)  {  N*0,  1  *  N'  } 

(ii)  {  N*0,  1  €  N’,  N’  =  N  } 

(iii)  {  N*0,  1  «  N\  N*\{1}  =  N\{1}  } 

Both  (i)  and  (iii)  are  end-consistent,  whereas  (ii)  is  not  -  because  it  fails  to  cover  the  case  N  =  {1}. 

We  are  especially  interested  in  specifications  for  which  end-consistency  can  also  be  established 
statically.  A  sufficient  condition  is  that  the  event  in  question  is  what  we  shall  call  "well-formed". 

Proposition.  Let  £  be  an  event,  and  G  be  the  guard  for  that  event;  then  E  is  end-consistent  if  E  is 
consistent  and  G  =>  ipc(E);  in  this  case  it  follows  that  ipc(E)  =  G. 

The  relation  characterised  by  a  mixed  predicate  W  may  be  conceptually  "inverted"  through  another 
renaming  over  its  free  variables,  denoted  as  1/V°,  which  is  obtained  by  specially  superscripting  all 
undashed  variables  (so  that  v°  now  stands  for  the  "previous"  value  of  v)  and  undashing  all  dashed 
names  (so  that  v  now  stands  for  its  new  "current"  value  v' ).  Thus  £°  expresses,  as  an  undashed 
predicate,  the  net  "effect"  once  some  event  E  has  occurred,  conditioned  on  the  existence  of  a 
previous  state  in  which  that  event  was  admissible. 

Definition.  Let  E  be  an  event;  then  its  weakest  postcondition,  denoted  wpc(E),  is  obtained  by 
existentially  quantifying  over  all  previous  variable  names  (of  the  form  v°)  occurring  free  within  E°. 

The  term  "weakest"  is  used  here  to  emphasise  that  this  condition  does  not  depend  upon  any  more 
specific  properties  of  that  previous  state.  However,  by  construction  we  have  that  wpc(E)  => 
wpc(F)  =>  (wpc(R)  a  S),  which  is  strong  enough  not  only  to  establish  the  (potentially  weaker) 
postconditions  R  ,  as  explicitly  specified  within  the  corresponding  event  schema,  but  also  to 
preserve  the  invariants  associated  with  its  underlying  stateS,  since  these  are  both  included  into  the 
corresponding  final  state  F  for  that  event 

Part  of  the  conciseness  of  our  conventions  comes  from  the  fact  that  postconditions  serving  solely  to 
"restore"  the  state  invariants  may  be  omitted,  as  they  are  present  implicitly.  More  important  is  the 
omission  of  conditions  which  state  only  that  some  aspect  of  the  state  remains  "unchanged",  since 
these  latter  properties  may  be  inferred  (and  are  therefore  inherited)  from  previous  "history". 

Definition.  A  history  is  a  finite  sequence  of  event  predicates,  h  =  (£*,... ,Efc),  where  each  £, 
corresponds  to  an  individual  occurrence  of  some  event  belonging  to  the  class  in  question. 

We  wish  to  consider  situations  in  which  h  =  h°  A  {£),  for  a  given  initial  history  h°  and  event  £, 
such  that  a  set  B,  comprising  all  predicates  which  hold  after  h°,  characterises  the  previous  state 
before  that  occurrence  of  E.  For  h  to  exist,  E  must  be  admissible  at  that  point,  implying  that  B  is 
consistent  with  ipc(E).  The  properties  holding  after  this  event  are  given  by  wpc(E). 
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The  weakest  postcondition  for  any  event  depends  upon  how  its  explicit  postconditions  r  e  R  are 
actually  written.  Compare  the  effect  of  different  expressions  over  a  state  variable  N  of  type 
set[NATj,  according  as  some  predicate  b  (say,  0  e  N)  is  or  is  not  known  to  hold  in  B: 

r  wpc(r)  wpc(b  a  r) 


V 

1  e  N* 

1  6  N 

1  6  N 

I 

N'  =  N  u  {1} 

1  e  N 

0  e  N  a  1  e  N 

1  «  N’ 

1  <£  N 

1  €  N 

m 

N'  =  N\{1) 

1  e  N 

Oe  NaI e  N 

Such  examples  show  that  wpc(p1/\p2)  is  not  in  general  equivalent  to  wpc(pl)  a  wpc(p2),  even 
where  the  conjuncts  of  the  latter  are  equivalent,  although  we  do  the  following: 

Proposition :  If  pi  =*  p2  then  ipc(pl)  =>  ipc(p2)  and  also  wpc(pl)  =>  wpc(p2),  whence 
equivalent  predicates  have  equivalent  implied  preconditions  and  weakest  preconditions. 


We  would  argue,  however,  that  the  main  use  of  such  forms  as  N’  =  N  u  {1}  and  N’  =  N\{1}  above 
is  simply  to  "carry  forward"  history,  which  is  tantamount  to  overspecification  if  the  only  intended 
effect  of  the  operations  in  question  is  to  insert  or  delete  the  value  1 .  It  is  for  this  reason  that  we 
have  introduced  inheri fence  of  properties  which  can  be  inferred  from  history.  A  consequence  is 
that  the  weakest  postconditions  for  (b  a  r)  above  then  become  the  same  for  each  operation,  i.e. 
(Oe  N  a  1  e  N)  on  insertion  and  (Oe  N  a  1  e  N)  on  deletion,  irrespective  of  how  r  is  expressed. 

In  order  to  inherit  any  (undashed)  predicates  holding  in  B,  the  event  E  as  obtained  from  its  schema 
must  be  augmented  by  some  set  A  of  (mixed)  predicates  serving  to  re-establish  those  properties  for 

the  state  variables  after  that  event,  as  reflected  in  wpc(E  u  A);  but  A  must  be  such  that  this 
conjunction  remains  end-consistent.  The  strongest  possible  augments  assert  that  nothing  changes. 

Definition.  Let  B  be  some  previous  state;  then  any  predicate  of  the  form  (v’  =  v),  where  v  is  an 
undashed  variable  name  occurring  free  in  B,  is  termed  an  identity  for  B.  The  set  of  all  such 
predicates  is  denoted  identity(B). 

This  is  the  default,  when  R  is  empty.  But  if  any  "updates"  at  all  are  specified,  E  u  identity(B)  will 
not  be  end-consistent  Some  such  identities  may  be  appropriate  (and  indeed  this  is  how  the 
parameters  of  a  schema  are  held  constant,  since  their  names  cannot  be  written  in  dashed  form); 
normally,  however,  a  weaker  set  of  "neutral"  augments  must  be  chosen. 


Definition.  Let  B  be  some  previous  state;  then  a  mixed  predicate  p  over  the  state  variables  of  B  is 

S' 

ini  termed  neutral  with  respect  to  B  iff  identityfB)  =^>  p.  The  set  of  all  such  p  is  denoted  neutral(B). 

For  the  example  above,  neutral  predicates  over  N  will  have  the  general  form  (N'nM  =  NnM),  for 
some  specific  McNAT,  or  equivalently  (NVM  =  N\~M);  thus  they  include  (N’n{0}  =  Nn{0}). 


Definition.  Let  B  be  some  previous  state  and  E  be  an  event;  then  a  predicate  p  €  neutral(B)  is 

termed  neutral  with  respect  to  B  and  E  iff  the  set  B  u  E  u  {  p  }  is  end-consistent.  The  set  of  all 
such  p  is  denoted  neutral(B,E). 

Proposition.  The  set  neutral(B,E)  is  closed  under  disjunction. 

However,  neutral(B.E)  is  not  in  general  closed  under  conjunction.  Consider,  for  example,  the 
case  where  B  =  {1  <£  N  ,  2«  N  }  and  E  =  {  pi  v  p2),  with  pi  =  (N'=N\{1 })  and  p2  =  (  N’=N\{2}j; 
then  pi  and  p2 are  both  contained  in  neutral(B,E),  but  (pi /\p2)  is  not 

This  means  that  not  all  neutral  predicates  are  mutually  compatible.  To  ensure  that  only  such  forms 
are  chosen,  there  is  a  need  to  "filter"  these  choices,  as  follows. 

Definition.  Let  B  be  some  previous  state  and  E  be  an  event;  then  a  predicate  q  e  neutral(B)  is 

termed  central  with  respect  to  B  and  E  iff,  for  all  predicates  p  e  neutral(B),  the  set  B  u E  u  {p,q} 
is  end-consistent  The  set  of  all  such  q  is  denoted  central(B,E). 

Proposition.  The  set  central(B.E)  is  closed  under  disjunction  and  conjunction. 

With  regard  to  the  previous  example,  the  form  fM'Xfl  ,2}=N\{1 ,2}^  2  (plAp2)  is  included  in 
central(B.E).  The  required  inference  rule  may  now  be  defined  in  terms  of  this  set. 

Definition.  Let  h  be  a  history  and  r  be  an  undashed  predicate;  then  h  |=  r  (  r  is  inferred  from  h  ) 
is  defined  inductively  (over  initial  histories  h°  and  events  E)  by  the  following  rules: 

(i)  0  I  =tme 

(ii)  If  A(E)  |s  r  iff  3  p  e  H(h°),  q  e  centra /(  H(tf),E )  •  wpc(E  u  {p,q}  )=>  r 
wherein  H(h)  denotes  the  set  of  all  predicates  inferred  by  these  rules. 

Proposition.  The  set  H(h)  is  closed  under  conjunction.  (This  follows  from  the  closure  of 
central(B.E),  by  induction  on  the  length  of  h.) 

A  valid  objection  to  the  inference  rule  |2  given  above  is  that  the  choice  of  neutral  augments  depends 
upon  the  particular  history.  An  apparently  weaker,  but  static  (and  thus  practically  applicable) 
inference  rule  is  developed  below,  using  only  neutral  predicates  which  are  central  to  the  event  E 
itself  (where  we  assume  that  identity  (B)  and  neutral(B)  are  extended  to  mixed  predicates  in  the 
obvious  way). 

Definition.  Let  E  be  an  event;  then  a  predicate  q  e  neutral(E)  is  central  to  E  iff  q  e  central(B,E) 
for  all  states  B  such  that  B  u  E  is  end-consistent. The  set  of  all  such  q  is  denoted  central(E) . 

Definition.  Let  h  be  a  history  and  r  be  an  undashed  predicate;  then  h  |=  r  is  defined  inductively 
by  the  following  rules: 

(i)  0  1=  true 

(ii)  h°  A(£>  |=  r  iff  3  p  e  H(h°),  q  €  central(E)  •  wpc(  &j{p,cf) )  =*  r 
wherein  H(h)  now  denotes  the  set  of  all  predicates  inferred  by  these  static  rules. 

Proposition.  If  h  |=  rthen  h\sr  (since  central(B,E)  c  central(E)  for  all  states  B). 
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We  are  now  in  a  position  to  define  consistency  over  histories,  using  whichever  set  of  historical 
inferences  proves  most  convenient 

Definition.  A  history  h°  A(£)  is  end-consistent  iff  H(h°)  u  E  is  end-consistent;  ()  is  vacuously  end- 
consistent  A  history  h  is  consistent  (and  therefore  plausible)  iff  all  of  its  prefixes  are  end- 
consistenL 

Proposition.  If  Eis  end-consistent  and  ipc(E)  e  H(lf )  then  h°  A(£)  is  end-consistent 

If  E  is  statically  "well- formed”,  h°  A(£)  will  be  end-consistent  whenever  the  guard  G  for  that  event 
can  be  inferred  from  h°. 

The  behaviour  characterised  by  a  class  specification  can  now  be  modelled  in  terms  of  traces. 

Definition.  Assuming  some  association  of  sets  to  the  generic  names  appearing  within  a  given  class 
specification,  a  denotation  for  an  event  belonging  to  that  class  is  just  its  signature  with  any 
systematic  substitution  of  values  from  these  sets  for  the  parameter  names;  an  initial  denotation  is 
just  the  signature  of  the  class  after  such  substitution.  The  traces  for  that  class  are  the  prefix-closed 
set  of  finite  sequences  of  event  denotations,  each  of  which  begins  with  the  same  initial  denotation  . 

The  projection  of  a  denotation  is  a  model  for  (an  occurrence  of)  the  denoted  event,  wherein  the  free 
variables  corresponding  to  its  parameters  have  the  values  which  were  substituted  for  their  names 

within  that  signature.  A  trace  Eq^Ei . e*)  projects  onto  a  history  E0A(E1 . E^  iff  Ej  is  a 

projection  of  Ej.  A  model  for  the  behaviour  of  a  class  is  then  a  set  of  traces,  each  of  which  projects 
onto  a  consistent  history. 


4.  A  More  Realistic  Example 

This  section  is  entirely  devoted  to  the  development  of  a  somewhat  more  realistic  example.  The 
following  "roadmap”  gives  an  overview  of  both  the  example  to  be  considered  and  the  resultant 
system  architecture. 


The  specification  is  developed  exclusively  by  composition  and  refinement,  which  imposes  a 
"bottom-up"  method  of  proceeding;  otherwise,  the  order  of  presentation  is  arbitrary.  As  usual,  the 
first  stage  in  this  process  is  concerned  with  unique  identification. 


Partitions  are  uniquely  identified  as  elements 
drawn  from  some  carrier  set  P;  initially,  there 
are  no  such  parts  in  existence. 


Whenever  a  new  partition  is  first  defined,  its 
identification  is  distinct  from  that  of  any  other 
part  currently  in-use. 


PID 


An  existing  part  identifier  may  be  nullified,  in 
which  case  it  is  deleted  from  the  set  of  those 
currently  in-use. 


PID.  Null  Part(p) 
p:  Part 


Based  on  this  part  identification,  the  structure  of  a  partitioned  information  system  is  now  specified. 


The  information  in  the  system  consists  of  a 
separate  sequence  of  data  for  each  defined  part, 
corresponding  to  the  (historical)  order  in  which 
successive  data  were  added  to  that  particular 
partition.  The  actual  data  values  belong  to 
some  underlying  set  D,  which  is  not  further 
specified  at  this  level. 


PIS - 

PID 


Info:  Part  ->  seq  [D] 


When  a  new  part  is  first  created,  the  associated 
sequence  of  information  is  empty. 


When  an  existing  part  is  nullified,  information 
previously  associated  with  that  partition  is  no 
longer  known  within  the  system. 


PIS.  Null  Part  (p)  _ 

PID.  Null  Part  (p) 


When  a  new  datum  is  added  to  an  existing  part, 
it  becomes  the  latest  in  the  sequence  associated 
with  that  partition. 


PIS.  Add  Data  (d,p) 


Specifying  the  structure  of  the  information  itself  is  an  overriding  concern  in  the  design  process  for 
many  such  systems.  Here,  however,  these  issues  have  been  abstracted  almost  completely  (so  that 
they  may  be  addressed  as  an  orthogonal  aspect  at  some  later  stage).  The  only  commitment  is  to 
partitioning,  where  the  information  associated  with  each  part  is  truly  independent;  thus  this 
abstraction  would  not  be  adequate  for  relational  structures.  We  have  also  postulated  an  historical 
interpretation,  as  opposed  to  "overwriting  semantics",  for  reasons  which  will  become  apparent. 
This  decision  could  be  reversed  later,  by  encapsulating  the  model  so  as  to  allow  access  to  only  the 
most  recent  data  for  each  partition. 
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A  characteristic  of  most  database-like  systems  is  the  ability  to  support  multiple  views  of  the  same 
information.  Such  views  must  first  be  identified. 


Views  are  uniquely  identified  as  elements 
drawn  from  some  carrier  set  V;  initially,  no 
views  are  defined. 


VID _ 

View:  set  [V] 

View'  =  0 


When  a  new  view  is  defined,  its  identification 
is  distinct  from  any  other  view  in  existence. 


When  a  view  is  nullified,  its  identifier  is  no 
longer  known. 


VID.  Null  View  (v) 
v:  View 


v  «  View' 


This  view  identification  is  then  combined  with  the  partitioned  structures  specified  previously  to 
define  a  multiview  information  system ,  followed  by  promotion  of  the  operations  on  VID  and  PIS. 


In  an  information  system  with  multiple  views, 
each  partition  originates  in  one  particular  view, 
but  may  be  visible  (as  a  component)  in  many 
views;  every  part  is  a  component  of  the  view  in 
which  it  originates. 


VIS 
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New  views  may  still  be  created  at  any  time  VIS.  New  View  (— » v)  _ 

(without  further  restriction). 

VID.New  View  (-» v) 


Only  views  which  are  not  currently  in  the  role 
of  the  originator  for  any  existing  partition  may 
be  nullified. 


VIS.  Null  View  (v)  _ 
VID.Null  View  (v) 


v  e  cod  (Orig) 


Each  new  part  is  created  from  some  specified 
view,  which  thereby  becomes  the  originator  for 
that  partition. 


VIS.  New  Part  (v  ->  p)  _ 
PIS.New  Part  (-» p) 


v:  View 


Orig'(p)  =  v 


A  partition  may  only  be  nullified  from  the  view 
in  which  that  part  originates. 


Only  the  originating  view  for  a  given  part  may  VIS.  Add  Data  (d,p,v)  _ 

add  data  to  that  particular  partition. 

PtS.Add  Data  (d.p) 


v:  View 


Additional  operations,  specific  to  a  multiview  system,  are  also  introduced  at  this  level. 


i 
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The  originating  view  for  any  partition  may  be 
changed  by  its  current  originator,  provided  that 
the  part  in  question  is  already  a  component  of 
the  view  designated  as  the  new  originator. 


VlS.Chg  Orig  (p,v,u) 

p:  Part 
v,u:  View 


u  *  v 
pOrig  v 
p  Comp  u 


Orig'(p)  =  u 


A  part  may  be  made  newly  visible  in  some  view 
v  from  another  view  u  wherein  it  is  already  a 
component 


A  component  part  may  be  excluded  from  any 
view  which  is  not  (currently)  the  originator  for 
that  partition. 


VIS.  Ex  View  (p,v) 

p:  Part 
v:  View 


(p,v)  e  Comp\Orig 


(p,v)  <&  Comp’ 


All  of  the  foregoing  operation  definitions  embody  design  decisions  which  are,  in  some  sense, 
arbitrary;  they  could  just  as  easily  have  been  made  (and  specified)  differently. 
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At  this  point  we  turn  to  specifying  the  underlying  network.  Again  the  first  step  is  concerned  with 
uniquely  identifying  the  nodes  in  such  a  configuration. 


Nodes  are  uniquely  identified  as  elements  of 
some  set  N;  a  subset  of  the  nodes  so  identified 
are  said  to  be  "up"  at  any  given  time. 


NID 


When  a  new  node  is  introduced  it  is  given  a 
distinct  identifier;  such  newly  defined  nodes 
are  initially  "down"  (i.e.  not  up). 


NID.  New  Node  (-» n) 
n:  ~  Node 


n  e  Node' 


An  identified  node  may  be  (definitively)  deleted 
from  the  set  of  known  nodes  within  the  system. 


NID.  Null  Node  (n) 
1  n:  Node 


n  «  Node' 


Nodes  which  are  down  may  be  brought  up. 


Nodes  which  are  up  may  also  go  down. 


NID.  Node  Up  (n) 


ft 

u£ 

„  The  network  infrastructure  is  then  characterised  as  a  further  refinement,  which  introduces  the 
interconnection  of  individual  nodes. 

5: 

Every  defined  node  is  connected  to  itself,  and 

NIS  _ 

« 

may  also  be  connected  to  other  such  nodes; 
these  connections  are  considered  to  be  bi¬ 
directional.  A  node  is  said  to  be  accessible  from 
another  node  if  there  exists  some  sequence  of 
interconnected  nodes  leading  from  one  to  the 
other,  where  all  of  the  nodes  in  question  are  up. 

NID 

s 

1 

Conn;  Node  <->  Node 

Acc:  Node  <+>  Node 

vv 

9 

&■ 

Conn  =  Conn*1 
id[Node]  c  Conn 

Acc  =  ( Conn  n  UpxUp )+ 

£ 

Additional  operations  at  this  level  might  include  events  such  as  the  following:  1 

•  • 

-y 

It  is  possible  to  establish  a  new  connection 
between  previously  unconnected  nodes. 

NIS.MakeConn  (n.m) 

n.m:  Node 

i 

V, 

■1*. 

(n,m)  <t  Conn 

V\ 

ft 

(n.m)  e  Conn' 

$ 

e 

\.- 

Existing  connections  may  be  broken  at  any  time 
(but  a  node  cannot  be  disconnected  from  itself). 

NIS.BreakConn  (n.ml 

n,m:  Node 

m  •  , 

£ 

«J 

n  *  m 

n  Conn  m 

V, 

(n,m)  e  Conn’ 

i* 

vi 

> 

« • 

» 

Quite  obviously,  this  network  definition  is  merely  a  "placeholder",  which  is  introduced  more  for 
purposes  of  illustration  than  for  its  actual  substance.  In  practice,  it  should  be  replaced  by  a 
(sufficiently  abstract)  specification  for  the  real  network  infrastructure  upon  which  the  system  of 
interest  is  meant  to  be  constructed. 
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Before  proceeding  to  our  objective  of  a  physically  distributed  system,  it  is  helpful  to  introduce  an 
intermediate  abstraction  corresponding  to  a  separable  information  system.  This  is  formulated  as  a 
further  refinement  to  the  multiview  systems  already  specified. 


There  is  an  independent  projection  for 
each  separate  component  (part,  view) 
so  that  the  sequences  of  data  associated 
with  the  same  partition  in  different 
views  need  not  be  identical;  the  length 
of  a  given  projection  is  the  span  of  that 
component.  The  set  of  such  projections 
for  the  views  in  which  each  part 
originates  is  exactly  equal  to  the 
information  within  the  system  as  a 
whole.  The  projections  for  other 
components  may  lag  behind. 


SIS _ 

VIS 

Proj:  Comp ->  seq[ID] 
Span:  Comp  ->  NAT 


Span  =  (#)oProj 
Projo(id[Part]  &  Orig)  =  Info 
Projo(id[Part]  &  Comp)  c  pref'1  °lnfo 


These  latter  invariants  are  expressed  in  terms  of  the  operator  to  join  two  relations  with  a  common 
domain: 


(A  <+>  3)  x  {A  <+>  C)  ->  (A  <+>  (B  x  C) ) 


I  a(Ri&  R2K  b.c )  <=>  aR-jbAaRpc 

The  "lag"  is  specified  as  some  prefix  of  the  original  information,  where  this  relation  has  its  usual 
definition: 


_pref_:  seq[D]  <->  seq[D] 


p  pref  x  <=>  3s:  seq[D]«(pAs=x) 


It  follows  from  the  above  specification  that  component  projections  for  the  same  partition  differ  only  in 
their  respective  spans;  they  must  agree  on  prefixes  of  equal  length,  as  it  is  not  possible  to  "rewrite 
history".  All  operations  on  VIS  may  be  promoted  directly  (since  each  part  can  only  be  extended  from 
the  view  in  which  it  originates).  In  addition,  some  means  must  be  provided  for  dealing  with  out-of- 
date  projections: 


A  particular  component  part  in  view  v 
may  be  brought  up-to-date  with  respect 
to  that  same  part  in  another  view  u, 
provided  that  no  information  would  be 
lost  as  a  result 


SIS.  Update  (p,v,u) 


Finally,  a  distributed  information  system  is  obtained  by  mapping  the  separable  views  (established  at 
the  previous  level)  onto  some  given  network  infrastructure. 


A  particular  node  is  designated  as  the  host 
for  each  view,  which  thereby  determines  a 
corresponding  base  for  every  component. 
However,  there  is  at  most  one 
representative  sequence  of  data  for  each 
partition  at  any  node,  whence  the 
projections  of  that  component  part  are 
identical  in  all  views  sharing  the  same 
host 


DIS _ 

SIS;  NIS 

Host:  View  ->  Node 
Base:  Comp  ->  (Part  x  Node) 
Repr:  (Part  x  Node)  +>  seq[D] 


Base  £  ( id[Part]  ®  Host ) 
Proj  =  Repr  o  Base 


The  required  correspondence,  (Part  x  View)  ->  (Part  x  Node),  is  specified  above  in  terms  of  a 
relational  producr. 


®_:  (A  <+>  C)  x  (B  <+>  D)  ->  ( (A  x  B)  <+>  (C  x  D) ) 


(a,b)(R-|  ®  R2)(c,d)  <=>  aR-jCAbR2d 


The  operations  appropriate  to  such  a  distributed  information  system  would  mainly  be  introduced  as 
promotions  from  the  previous  level,  whilst  taking  into  account  any  additional  constraints  imposed  by 
the  physical  distribution.  For  instance: 


A  component  may  be  brought  up-to-date 
with  respect  to  another  view  provided  that 
the  hosts  for  both  views  are  mutually 
accessible.  (NB:  this  will  update  that 
component  part  for  all  views  on  the  same 
host) 


DIS.Update  (p,v,u)  _ 

SIS.  Update  (p.v.u) 

Host(u)  Acc  Host(v) 


Certain  technically  more  complex  issues  (e.g.  relating  to  restart  and  recovery)  might  also  begin  to  be 
tackled  at  this  level,  in  conjunction  with  promoting  specific  events  inherited  from  the  underlying 
network  definition.  At  this  point,  however,  the  overall  system  structure  announced  at  the  outset  is 
essentially  complete. 


It  should  be  observed  that  further  development  of  the  foregoing  specification  is  limited  by  its 
somewhat  "Olympian"  perspective,  wherein  only  rather  global  properties  of  the  system  have  so 
far  been  characterised.  Despite  this  objection,  formalisation  of  such  a  top-level  design  is  a  useful 
first  step.  For  the  particular  example  considered  here,  subsequent  refinements  (leading  towards  an 
actual  implementation)  ought  properly  to  be  formulated  as  a  decomposition  into  independent 
processes,  based  on  the  concepts  of  communication  and  synchronisation  developed  by 
Milner[1980]  and  Hoare[1985].  These  questions  will  be  addressed  in  a  sequel  to  this  paper. 
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An  experiment  is  described  involving  a  new  approach  to  system 
specifications.  The  process  of  developing  a  formal  specification  from  an 
informally  specified  distributed  information  system  concept  forms  the  basis 
of  the  experiment.  The  new  approach,  which  is  based  on  formal  mathematical 
techniques,  is  introduced  gradually  as  the  experiment  is  described.  An 
attempt  is  made  to  document  the  experience  and  lessons  learned  as  the 
experiment  progressed. 


\ — 


Introduction 


An  investigation  was  begun  a  few  years  ago  into  potential  applications  for 
the  newly  emerging  distributed  systems  technology  to  the  Army's  Air/Land 
Battle  Forces.  This  investigation's  purpose  was  to  help  motivate  and  give 
direction  to  a  research  effort  on  distributed  systems  that  was  beginning  at 
the  time.  The  first  application  considered  was  a  distributed 
communication/database  system  for  battalion  situation-status  reporting  in  a 
battlefield  environment. 

An  informal  specification  of  a  somewhat  abstract  version  of  this 
situation-status  reporting  system  formed  the  starting  point  for  the 
experiment  that  is  reported  here  on  a  new  approach  to  system  specification 
using  formal  mathematical  techniquesCl] .  Although  the  approach[2,  3]  has 
been  under  investigation  for  several  years  (mainly  at  the  Programming 
Research  Group  at  Oxford  University  in  England),  it  is  still  evolving  and  is 
not  yet  in  its  final  state. 

Although  there  were  no  distinct  roles  given  to  each  of  the  authors,  the 
intent  was  to  simulate  a  small  team  containing  representation  from  three 
disciplines.  The  first  are  the  "user  representatives",  those  who  understand 
the  need  for  the  system  being  designed  and  the  intended  application,  the 
second  were  the  designers,  those  who  are  responsible  for  the  intended 
implementation.  Both  of  these  are  assumed  to  have  an  intuitive  understanding 
of  the  formal  techniques  that  will  be  used  to  reason  about  the  design  that 
is  sought.  The  third  are  the  "analysts"  who  are  assumed  to  be  fluent  in  the 
formal  techniques  described  here. 

The  formal  techniques  used  here  are  still  under  development  and  the  intent 
primarily  was  to  experiment  with  the  approach  evaluating  its  current 
utility.  This  possibly  might  clarify  some  aspects  of  the  approach  that  could 
be  improved.  The  hope  of  gaining  a  deeper  understanding  of  the  distributed 
system  itself  was  not  an  insignificant  part  of  our  motivation. 

The  preceding  paragraph  was  the  primary  motivation  for  the  experiment, 
however  the  process  described  in  this  paper  can  be  viewed  by  the  reader  as  a 
design  effort  for  a  certain  aspect  of  the  system,  namely  the  distributed 
nature  of  an  information  management  system.  Viewed  in  this  way,  it  is  hoped 
that  the  reader  will  gain  some  of  the  appreciation  that  was  gained  by  the 
authors,  of  the  insite  into  solving  complex  problems  of  system  design 
provided  by  the  precision  and  clarity  of  mathematical  reasoning. 

The  formal  notation  used  in  the  approach  will  be  introduced  gradually  as  the 
paper  progresses. 


An  Informal  Specification  of  a  Distributed  Database  System 

The  informal  description  of  a  distributed  communication/database  system 
concept  given  here,  was  written  before  the  formal  specification  was 
attempted.  Since  one  of  the  expected  benefits  of  doi.ng  a  formal 
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specification  is  additional  insights  into  the  concepts  being  modeled,  it 
should  be  of  some  interest  to  revisit  this  starting  point  after  the  formal 
specification  is  developed. 


1 
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Consider  a  collection  of  computer  work  stations  physically  separated  over 
some  distance  (e.g.,  a  few  miles)  interconnected  by  some  electronic 
communications  medium  (e.g.,  packet  radio).  The  interconnection  pattern  need 
not  be  total  but  it  should  be  nonetheless  possible  for  any  work  station  to 
communicate  with  any  other  work  station.  The  only  physical  devices 
(hardware)  used  to  implement  the  system  are  those  physically  located  with 
each  work  station.  This  would  include  at  least  a  computer,  a  keyboard  and 
screen,  some  secondary  storage,  and  the  communication  equipment.  The 
hardware  at  each  station  is  identical.  The  system  must  be  mobile  in  the 
sense  that  the  stations  will  be  moving  from  time  to  time  to  different 
physical  locations.  Moving  will  probably  involve  a  logging  out  process 
followed  later  by  a  logging  in  process. 


Each  station  maintains  a  local  file  system.  The  basic  unit  managed  by 
these  file  systems  is  the  report,  which  is  similar  to  the  programming 
language  concept  of  a  record,  as  found  for  example  in  Pascal.  A  report 
consist  of  a  fixed  number  of  fields,  each  being  an  information  unit  of  some 
•*v  tyPe*  The  number  of  the  fields  and  the  type  assigned  to  any  field  can  be 
changed  only  at  what  we  will  call  "system  initialization  time".  Such 
alterations  to  the  structure  of  a  report  will  not  be  a  frequent  occurrence. 
Examples  of  field  values  are:  a  numeric  value,  say  INTEGER  or  REAL,  or  a 
.%  tuple  of  numeric  values,  or  a  string  of  characters. 


The  local  file  system  will  manage  a  collection  of  such  reports,  one  of 
f-.  which  will  be  designated  as  the  current  report.  The  file  system  will  be  able 

■  to  modify  the  values  of  any  of  the  reports  in  the  collection,  create  new 
reports,  delete  reports,  etc.  An  editing  capability  will  be  available  at 

•  each  station. 

1* 

The  basis  for  intercommunication  among  the  stations  is  the  notion  of 
“global  data  areas".  The  collection  of  stations  making  up  a  particular 

■  system  can  involve  any  number  of  global  data  areas.  Any  global  data  area, 

■  say  G,  has  a  number  of  stations  inputing  information  to  it  and  a  number  of 
stations  outputing  information  from  it.  An  inputing  station  for  G  is  not 

■»’.  necessarily  also  an  outputing  station  and  vice  versa.  To  be  an  inputing 
£•'  station  to  G  means  that  W  can  send  a  copy  of  a  report  to  G.  The  totality  of 
all  information  held  by  G  is  the  collection  of  all  reports  sent  by  the 
U  inputing  stations  for  G.  An  inputing  station  can  have  at  most  one  report  in 

V  G  at  any  time.  It  can  have  no  reports  in  G,  it  can  remove  a  report  and 

■  replace  it  by  a  new  report  or  not  replace  it  at  all.  Outputing  stations  for 
G  can  query  the  information  in  G.  Precisely  what  the  query  capabilities  are 
v.  i 3  open  at  thi3  time.  We  may  want  to  restrict  the  query  capabilities  of 

■V  particular  outputing  stations.  Since  the  only  hardware  for  these  systems  is 

at  the  physical  location  of  the  stations,  processing  support  for  the  global 
»-  data  areas  must  be  at  the  stations. 

The  most  important  attribute  for  the  intended  application  of  these  systems 
is  ''robustness”,  that  is,  the  ability  of  a  system  to  maintain  a  continuity 
^  of  service  even  under  severe  operating  conditions  and  as  individual  stations 
h  go  down.  A  station  can  go  down  either  by  an  orderly  log-out,  or  abruptly  (by 
malfunctioning  or  by  being  destroyed  e.g.  by  hostile  action).  If  G  has  input 

•  stations  Wl,...,Wm  and  output  stations  W1 ',..., Wm',  then  if  Wi  goes  down. 
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its  most  current  report  in  G  (if  any)  continues  to  be  accessible  to  the 
output  stations  which  can  continue  to  function  to  the  maximum  extent 
possible.  Likewise,  if  some  Wj*  goes  down,  the  rest  of  the  system  must 
function  with  no  change  other  than  the  fact  that  Wj'  will  not  be  performing 
queries.  In  other  words,  if  any  station  goes  down,  whether  or  not  it  is  an 
inputing  or  an  outputing  station  for  G,  the  rest  of  the  system  must  be  able 
to  function  normally.  All  this  implies  that  a  global  data  area  cannot  be 
implemented  at  any  one  station.  The  situation  is  similar  for  multiple 
stations  going  down  at  once.  Other  problems  are  aggrevated  when  multiple 
stations  go  down  (e.g.,  problems  of  communication  connectivity).  We  leave 
these  issues  open  for  now. 

The  question  of  the  robustness  of  a  system  also  includes  the  question  of 
data  consistency  and  currency.  If  W  updates  a  report  in  G,  then  after  "some 
reasonable  period  of  time",  all  outputing  stations  for  G  should  get  this  new 
report  instead  of  the  older  version.  At  any  moment  of  time,  two  outputing 
stations  for  G  should  always  get  information  extracted  from  the  same 
versions  of  a  given  report. 


Beginning  the  Experiment 


We  decided  to  begin  by  trying  to  formulate  the  essential  concepts  underlying 
•  this  technology,  as  opposed  to  beginning  the  specification  of  a  particular 
system.  We  thus  stepped  back  from  the  particular  system  with  the  expectation 
that  the  essential  concepts  would  form  a  framework  for  the  resulting  system 
specification.  Essentially  what  we  planned  to  do  first  was  to  look  at  the 
class  of  such  systems,  and  thus  avoid  imposing  bounds  too  soon. 

(This  use  of  generalization,  which  follows  naturally  from  the  mathematical 
nature  of  the  approach  to  specification,  leads  to  better  long  term 
maintainability  properties  in  the  resulting  system,  as  requirements  changes 
are  easily  accommodated.  The  maintainability  of  a  system  is  a  direct 
consequence  of  its  ability  to  accomodate  changes  in  the  requirements.  The 
existence  of  an  explicit  framework  for  a  system's  design  based  on  the  class 
of  systems  it  belongs  to,  leads  to  a  high  probability  that  a  change  fits 
within  that  framework,  unless,  of  course,  the  change  places  the  system 
outside  that  class.) 

After  some  discussion,  the  following  three  concepts  seemed  central. 

(1)  different  "views"  inside  a  distributed  system, 
v  (2)  "virtual  nodes"  that  need  not  physically  exist,  and 

(3)  "replication"  or  redundancy. 

-  The  first  goal  was  to  give  some  clarity  and  precision  to  these  notions. 
Hopefully  we  could  then  study  their  implications  to  the  design. 


The 


Basic  Concepts. 

users  of  the  system  are  visualized  as  the  "originators"  of  information 


in  the  system.  Each  information  unit  so  generated  is  a  "report"  and  for  now 
there  is  no  need  to  consider  the  structure  of  individual  reports. 

Each  user  will  define  a  sequence  of  such  reports,  namely  the  history  of  all 
the  reports  this  user  has  generated.  Each  user  is  capable  of  appending 
another  report  to  this  sequence  at  any  time  (i.e.,  generating  another 
report ) . 

INF  =def  seq  RPT 

(Certain  mathematical  concepts  are  considered  standard  and  will  be  used 
freely,  among  these  is  the  set  of  sequences  of  elements  from  some  other  set, 
for  example,  the  above  expression  states  that  INF  is  the  name  of  a  set 
defined  as  the  set  of  all  finite  sequences  over  a  set  RPT.  Looking  back,  we 
should  have  used  the  identifier  INFO  instead  of  INF,  and  we  should  have  kept 
things  more  general  by  using  the  identifier  DATA  rather  than  RPT.  The  choice 
of  identifiers  for  the  various  concepts  introduced  is  not  a  trivial  matter. 
It  is  an  important  factor  in  the  readability  and  clarity  of  the  notation.  We 
in  fact  use  "info"  for  a  related  concept  later,  and  we  do  eventually  drop 
the  name  INF  and  change  RPT  to  DATA.  The  the  notational  system  being 
described  has  the  important  attribute  of  encouraging  experimentation  by 
making  the  process  of  changing  and  improving  the  concepts  being  defined 
rather  easy.  As  we  will  see,  these  changes  and  improvements  can  be  more 
substantial  than  just  changing  identifiers.) 


The  Initial  Formal  Specification. 


At  this  early  stage  we  chose  to  model  the  system  users  or  "originators"  by  a 
partial  mapping  "orig"  from  a  set  NID  (node  identifiers)  to  INF.  Note  that 
at  this  stage  we  were  conceptually  identifying  the  concept  of  "node"  and 
"user" 

|  Orig  :  NID  -|->  INF 
I 

The  set  NID  is  intended  as  the  collection  of  all  possible  names  to  be  used 
for  originators,  this  includes  originators  that  may  enter  the  system  in  the 
■  future.  Any  element  of  NID  in  the  domain  of  Orig  is  being  used  to  name  an 
originator  currently  in  the  system,  and  its  value  under  the  mapping  is 
(  intended  to  model  the  sequence  of  reports  issued  by  the  originator  from  the 
-•  time  he  entered  the  system.  Note  this  sequence  of  reports  can  be  empty. 

Continuing  we  defined 

Curr  :  NID  -!->  RPT 

..The  mapping  Curr  (current  report)  has  this  form  (its  "signature"). 
**_  Inuitively,  Curr  assigns  to  an  element  of  NID  in  its  domain  of  definition 
the  most  current  report  issued  by  the  "node".  Curr  is  defined  by: 

Curr  =  Last(  Orig) 

which  gives  the  last  element  in  the  sequence  (Orig). 


Conceptual  Modules  and  Semantic  Operators 


An  important  aspect  of  the  notation  used  in  this  approach  to  formal 
specification  is  that  of  a  "conceptual  module".  The  following  was  the  first 
conceptual  module  attempted  for  this  application.  It  was  an  initial  attempt 
at  a  definition  of  the  concept  of  a  "node". 

Node(n) 

I  - 

I  n  :  NID 

I 

I  Own  :  INF 

I 

I  Oth  :  VIEW 


Each  node  n  is  considered  to  consist  of  its  name  (an  element  from  the  set 
NID  of  node  identifiers),  a  sequence  in  INF  (the  node's  "own"  information 
history),  and  a  "view"  of  the  totality  of  all  information  in  the  system.  The 
concept  of  VIEW  was  one  of  the  notions  considered  central  and  at  this  point 
was  yet  to  be  made  precise. 

Another  conceptual  module  considered  at  this  early  stage  was: 

INFO 

I  - 

I  Orig  :  NID  ->  seq  RPT 


I  range(Orig)  *  {<  >} 


This  module  was  an  attempt  to  characterize  the  totality  of  all  information 
in  the  system.  The  mapping  "Orig"  (which  here  is  total)  associates  with  each 
element  of  NID  a  sequence  of  reports.  Here  all  of  the  potential  node 
identifiers  are  already  associated  with  RPT  sequences,  the  unused  names  are 
be  mapped  to  empty  sequences.  The  expression  below  the  double  line  in  the 
module  specifies  "initial  conditions".  Here  the  report  sequences  are  all 
initially  empty. 

INFO  contained  a  "semantic  operator"  which  makes  possible  the  generation  of 
a  report  by  a  particular  user. 

INFO. Issue(n,  r) 

I 

I  n  :  NID 
I  r  :  RPT 


Orig’(n)  =  Orig(n)  *  <r> 


The  meaning  of  this  "semantic  operator"  (for  the  conceptual  module  INFO)  is 
that  given  a  node  identifier  n  and  a  report  r,  r  is  placed  as  the  latest 
entry  in  the  node's  history  of  reports.  Hence,  a  new  report  has  been 
generated.  In  the  notation  the  prime  (')  symbol  is  used  to  indicate  the 
condition  of  a  mathematical  entity  after  an  operation  has  been  applied. 

The  concept  of  a  "view"  mentioned  above  is  intuitively  the  idea  of  a  node 
"seeing"  some  part  of  the  total  information  available  in  the  system.  Our 
first  attempt  at  a  formal  definition  took  the  following  form. 

VIEW(n) 

I 

I  n  :  NID 

I 

I  Own  :  3eq  RPT 

I 

I  Inf  :  NID  - 1 ->  seq  RPT 


I  I n  f ( n )  =  own 

I 

1  Inf  contained  in  Orig 

The  identifier  "inf"  (information)  which  was  earlier  used  to  name  the  set  of 
all  finite  sequences  from  RPT,  is  now  being  used  for  a  different  role.  The 
constraint  "Inf  contained  in  Orig"  states  that  Inf  is  some  part  of  the  total 
system  information.  This  attempt  to  capture  the  concept  of  a  view  was  soon 
improved  to  a  rewrite  of  the  INFO  module: 

INFO - 

I 

I  Orig  :  NID  ->  seq  RPT 

I 

I  View  :  NID  ->  (  NID  -|->  seq  RPT  ), 

I 

I 

I  View(n)(m)  contained  in  pre(  Orig(m)),  where  n  /=  m, 

1 

I  View(n) (n)  =  Orig(n),  and 

! 

I  n  in  dom(  View(n)). 


I  range(  Orig)  =  {<>} 

I _ 

The  operator  "pre"  on  sequences  is  the  set  of  all  initial  parts  (prefixes) 
of  its  sequence  argument.  The  first  constraint  above  states  that  "the  view 
that  n  has  of  m  is  always  some  initial  part  of  the  sequence  of  reports 
issued  by  m" .  The  "view"  that  a  node  has,  "view(n)",  is  specified  to  be  a 
set  of  some  of  initial  prefixes  of  the  histories  of  some  the  nodes  of  the 
system.  A  node  can  always  view  all  of  its  own  information.  A  node  can  always 
view  its  own  latest  information,  but  the  latest  information  generated  by 
some  of  the  nodes  may  not  be  locally  available  yet. 
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Refining  The  System. 


A  period  of  consolidation  and  redefinition  resulted  in  the  specification 
which  follows.  Such  consolidation  and  redefinition  seems  to  be  a  vital  part 
of  the  formal  specification  process.  It  is  here  that  most  of  "progress" 
seems  to  be  made. 


The  specification,  whose  exposition  makes  up  the  main  body  of  the  paper,  is 
composed  of  four  main  parts.  The  first  is  the  specification  of  the 


composed  of  four  main  parts.  The  first  is  the  specification  of  the 
functional  aspects  of  the  system,  the  second  describes  the  distributional 
aspects  of  systems,  the  third  combines  these  to  form  a  distributed 
information  system  and  the  fourth  extends  this  to  address  the  issue  of 
robustness . 


The  Formal  Specification. 


Both  the  formal  text  (conceptual  modules  and  semantic  operators)  and  the 
prose  which  follows  each  module  and  operator  are  considered  to  be  parts  of 
the  specification,  with  the  prose  being  commentary  and  interpretation  of  the 
formal  text. 


System  Functions. 


The  first  facet  of  the  system  to  be  specified  was  the  functionality,  which 
is  specified  independent  of  the  idea  of  distribution  which  is  added  later. 


Concept  SI:  System  made  up  of  Parts. 


SI [NAME] 


I  Part  :  FF ( NAME ) 


Part  =  [  } 


A  conceptual  module  SI  defines  the  Parts  of  the  system  in  terms  of  a 
"generic"  set  NAME.  (By  a  "generic  set"  we  mean  that  no  properties  of  the 
set  are  specified  other  that  the  fact  that  the  set  contains  a  supply  of 
elements,  and  that  it  can  be  determined  whether  or  not  two  arbitrary 
elements  of  such  a  set  are  equal.)  A  set  "Part”  (the  collection  of  parts  of 
the  system)  is  meant  to  be  an  abstraction  of  the  users  or  uning  programs  of 
the  system  and  is  specified  with  "signature"  FF(NAME)  which  means  that  Part 
will  always  be  a  finite  subset  of  the  set  NAME.  (The  use  of  the  term  "nodes” 
for  "the  system  users"  was  not  a  good  choice,  and  was  changed  to  separate 
the  two  concepts  it  embodied,  the  logical  parts,  users  or  user  programs  and 
data,  and  the  physical  parts,  or  nodes,  as  will  be  seen  below.)  The  set  Part 
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New  parts  can  be  added  to  the  system.  Parts  are  always  to  be  named  by  an 
element  from  NAME.  (The  symbol  indicates  that  "p"  is  an  explicit  result 
of  this  operation,  ie.  an  out  parameter. ) 


Sl.DelPart(  p  ) 


p  :  NAME 


p  not  in  Part' 

1 


Parts  can  be  deleted  from  the  system. 


Concept  S2: 


Describing  Information  in  the  System. 


i 

\ 


S2CDATA] 

I 

I  SI 

I 

I 

I  Info  :  Part  -l->  seq  DATA 

I 

I  Comp  :  FF(Part) 


t 


Comp  =  dom(Info) 


This  module  extends  the  first  module  Si.  In  this  way  new  modules  can  build 
directly  on  previously  defined  modules.  Info  and  Comp  are  implicitly  empty 
initially  since  Part  is  initially  empty. 


The  vague  terms  "Part"  and  "Comp"  (the  components  which  have  information) 
were  used  in  an  attempt  to  keep  the  development  as  general  as  possible.  The 
plan  was  that  we  would  give  the  identifiers  finally  adopted  a  great  deal  of 
thought  once  the  system  concepts  were  clearly  understood. 


S  2 . MakeCorap ( p ) 
I  p  i  Part 


p  not  in  Comp 


p  in  Comp ' 


Info'(p)  =  f  } 


System  "parts"  can  be  made  into  system  "components"  which  can  then  issue 
information. 


S2.Issue(c,  d) 


c  :  Comp 


d  :  DATA 


Info'(c)  =  Info(c)  *  <d> 


Only  system  "components"  can  issue  information.  This  source  of  information 
is  the  only  way  information  will  come  into  the  system.  (Notice  that  the 
formal  statements  are  not  difficult  to  read,  "Conceptual  Modules"  containing 
definitions,  constraints  on  values ( invariants )  and  (after  the  double  line) 
initial  conditions,  while  "semantic  operators"  contain  definitions, 
conditions  of  operation(preconditions )  and  (after  the  double  line) 
results (postconditions) . 


Concept  S3:  Entry  of  Information. 


Orig  :  FF(Comp) 


-N  The  group  of  current  originators  is  a  subset  of  "Comp"  and  is  initially 
>;  empty  (since  Comp  is). 


S3 .AuthOrig(c) 

I 

I  c  :  Comp 


c  in  Orig* 


S3 .NonOrig(c) 
I  c  :  Comp 


I  c  not.  in  Orig' 

Ability  to  origionate  information  can  be  given  and  withdrawn. 
S3.Issue(o,  d) 

I  - 

I  o  :  Orig 
I  d  :  DATA 


I  S2.Issue(o,  d) 

I _ 

Only  authorized  Originators  can  issue  information.  (Note  the  replacement  of 
a  "semantic  operation"  by  a  restricted  version. ) 

Concept  S4:  Viewing  Information. 

S4 

I  - 

I  S3 

I 

I - 

I  Vis  :  Part  <-!->  Comp 
I  View  :  Part  ->  (Comp  -|->  seq  DATA) 

I - 

I  Id(Comp)  contained  in  Vis 

I 

I  All  p.  All  c  :  (p,  c)  in  Vis  <=>  View(p)(c)  contained  in  Pre(Info(c)) 


Two  concepts  are  introduced  at  this  level.  Visibility  describes  which  parts 
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can  see  which  components'  information.  View  describes  what  information  a 
part  sees  for  each  component.  The  invariants  state  that  components  can  see 
their  own  information  and  a  part  sees  a  prefix  of  the  information  for  those 
■  components  in  its  view. 

V  S4.0pen(pp,  cc) 

:  |  ,  - - 

I  pp  :  FF(Part) 

I  I  cc  s  FF(Comp) 


cc  contained  in  vis'(pp) 

All  p,  All  c  :  (p,  c)  not  in  Vis  =>  View'(p)(c)  =  <  > 


Visibility  can  be  extended.  Added  views  are  initially  empty. 

•  * 

^  S4.Close(pp,  cc) _ 

v  I  pp  :  FF(Part) 

I 

"I  cc  :  FF(Comp) 


cc  not  contained  in  Vis'(pp) 


^  Visibility  can  be  removed. 

£  S4 .MakeComp(p) _ 

I  S2 .MakeComp(p) 

I _ 

i  — 

m  I  (p,  p)  in  Vis' 


When  system  parts  are  made  components,  they  are  able  to  see  the  information 
which  they  issue  (replacement  of  operation  by  extended  version,  so  as  to 
maintain  the  invariant). 


S4.Sync(c,  s,  d) 

I 

I  c  :  Comp 

I 

I  s,  d  :  Part 


c  in  im(Vis){s} 
c  in  im(Vis){d} 

#(View(d) (c) )  <=  #(View(s) (c) ) 


View'(d)(c)  =  View(s)(c) 


It  ia  possible  to  make  the  view  that  a  part (destination)  has  of  a 
component ' s ( c )  information  the  same  as  the  view  another  part (source)  has  of 
that  component's  information  (  ie.  to  synchronize  their  views),  as  long  as 
both  have  views  of  that  component's  information  and  the  source's  view  was 
later  (ie.  had  more  recent  versions). 

This  concludes  the  specification  of  the  functionality  of  the  system.  As  was 
stated  earlier  this  is  not  meant  to  be  a  specification  for  an  operational 
system  but  rather  a  class  of  systems.  As  such  it  includes  only  those 
functional  properties  that  were  deemed  to  be  essential  to  this  class  of 
systems,  ie.  distributed  information  systems. 


Distribution  of  a  System. 


The  next  set  of  "Conceptual  Modules"  addresses  a  different  aspect  of  the 
distributed  information  system,  those  concepts  essential  to  the  distributed 
nature  of  the  system.  As  this  aspect  looks  at  the  system  from  a  different 
perspective,  ie.  is  orthogonal  to  the  functional  view,  this  specification  is 
independent  of  the  functional  specification.  These  two  specifications  will 
be  combined  later  to  specify  both  aspects  of  the  system. 


£ 


Concept  PI:  Physical  Distribution  of  Nodes. 


P1[NN] 


Node  :  FF(NN) 

Conn  :  NN  <-|->  NN 
Path  :  NN  <- | ->  NN 


Conn  contained  in  Node  X  Node 
Conn  in  symm(NN) 

Path  =  Conn* 


Node  =  {  } 


This  conceptual  module  defines  the  basis  of  a  distributed  system  as  a 

collection  of  Nodes  which  are  Connected  together  allowing  those  Nodes  with  a 

Path  between  them  to  interact.  (Note  that  the  term  Node  is  used  here  in  a 

much  more  restricted  sense  than  its  use  in  the  first  attempt  at  a 

specification,  here  it  is  an  abstraction  of  a  single  computer  in  a  network 
of  computers.)  Node  will  always  be  a  finite  subset  of  names  from  another 
generic  set  of  names  (NN).  Only  existing  Nodes  can  be  Connected,  with  the 
existence  of  a  path  depending  on  the  closure  of  the  individual  Connections. 
Conn  is  a  symmetric  relation.  Node,  and  therefore  Conn  and  Path,  is  empty. 

Pl.NewNode(  ->  n  ) 

I 

I  n  :  NN 


n  not  in  Node 


n  in  Node' 


PI . DelNode(n) 


n  in  Node 


n  not  in  Node' 


Nodes  can  be  added  and  deleted, 


PI .Connect (n,  m) 


n,  m  :  Node 
n,  m  not  in  Conn 


(n,  m)  in  Conn' 


PI .DisConn(n,  in) 

St  I  “ 

I  n,  in  :  Node 

JW  ! 

S'  I  (n,  m)  in  Conn 


(n,  m)  not  in  Conn' 


Individual  Connections,  and  therefore  Paths,  can  be  added  to  and  removed 
from  the  network  of  Nodes. 


Concept  P2:  Activation/Deactivation  of  Nodes. 


Conceptual  module  P2  builds  on  the  network  of  Connected  Nodes  provided  by  PI 
to  add  the  concept  of  parts  of  this  system,  either  nodes  or  Connections,  not 
being  available  for  use  at  times  during  the  life  of  the  system. 


Up  :  FF(Node) 
Avl  :  FF(Conn) 
Acc  :  FF(Path) 


Avl  contained  in  Up  X  Up 


Acc  =  Avl* 


The  Nodes  that  are  working  are  a  finite  subset  of  the  existing  Nodes.  The 
Available  Connections  are  that  finite  subset  of  the  Connections  whose  Nodes 
are  Up.  The  Accessible  Paths  are,  likewise,  the  closure  of  the  available 
Connections . 


'  x,:  :  i;:  * 


,  P2 .NodeUp(n) 


n  s  Node 


n  not  in  Up 


n  in  Up' 


P2.NodeDn(n) 

I 

gm  I  n  :  Up 


Nodes  can  come  Up  and  go  down,  implicitly  causing  Connections  to  become 
^  Available  or  not  resulting  in  making  accessible/inaccessible  other  Nodes. 

PI  and  P2  contain  the  concepts  we  have  chosen  as  essential  in  the  modeling 
‘A  of  the  distributional  aspects  of  systems.  Note  that  we  have,  for  instance, 
m  chosen  not  to  explicitly  consider  that  connections  could  go  down  independent 
of  Nodes,  on  the  basis  that  to  a  user  of  a  connection,  either  the  connection 
or  the  node  going  down  appears  the  same. 

Distributed  Information  System:  Combining  Concepts. 

P 

The  functional  conceptual  modules  which  provided  for  the  Issuing  and  Viewing 
•N.  of  information  are  combined  with  the  distributional  conceptual  modules  to 
J‘;  form  the  concept  of  a  distributed  information  system.  This  allows  us  to 
consider  those  aspects  of  an  information  system  which  either  follow  from  its 
distributed  nature  (modules  D1  through  D3),  or  can  use  this  distributed 
™  nature  to  advantage  (module  R1 ) . 

Concept  Dl:  Distributing  Parts. 

v  Now  that  the  system  is  distributed,  Parts  (users  or  programs)  are  considered 
S;  to  exist  at  a  Node.  Note  that  this  choice  precludes  explicit  duplication  of 
■’  Parts,  as  will  be  seen  later  (conceptual  module  R1 )  the  normal  operation  of 
the  system  provides  enough  redundancy  so  that  explicit  duplication  is  not 
\  needed. 


'  DSysl- 


Home  :  Part:  ->  Node 


The  first  Distributed  System  conceptual  module  combines  and  directly  extends 
both  the  final  functional  and  distributed  configuration  modules.  Every  Part 
has  a  Home  Node.  (Again  since  Part  and  Node  are  both  initially  empty.  Home 
is  also. ) 


DSysl .NewPart(n  ->p) 


Sl.NewPart(  ->p  ) 


n  :  Dp 


."y  When  Parts  come  into  existence,  they  do  so  at  a  Home  Node.  (Promotion  of  a 
H  semantic  operation  to  include  the  effects  of  a  new  concept.) 


DSysl .Mo veHome(p,  n) 


p  j  Part  ?  n  :  Up 


Home(p)  /=  n 


(Home(p),  n)  in  Acc 


Home ' ( p )  =  n 


The  Home  of  a  Part  can  move. 


Concept  D2;  Activation/Deactivation 


/;  In  addition  to  the  long  term  existence  of  Parts  on  Nodes,  there  is  a  shorter 
£»  term  Activation/Deactivation  of  these  Parts  based  both  on  the  desires  of  the 
Part  and  the  status  of  the  Node  where  it  is  located. 


assess 


w^r.'rvr.T 


DSys2 


DSysl 


Site  :  Part  ->  Up 
Seas  :  FF(Part) 
Seas  =  dom(Site) 


Parta  can  only  be  active  (in  Seaaion)  when  they  are  at  a  Site  which  ia  Up.  A. 
Part 1  a  Site  can  be  different  from  ita  Home. 

DSys2 .Login (P,  n) 

I  - 

I  p  :  Part  ;  n  :  Up 
I  p  not  in  Seaa 


Site ' (p)  =  n 


DSya2 .LogOut (p) 

I 

I  p  :  Seaa 


p  not  in  Seaa' 


Parta  can  Log  in  or  out  at  a  Node  which  ia  Up, 

£ 

DSys2 .NodeDown(n) 

,  - 

*7  I  P2  .NodeDn(n) 


n  not  in  range(Site’) 


/  When  a  Node  goea  down,  there  are  no  Parts  at  that  node  in  Session,  ie. 
activity  at  that  Node  ceases. 

V'. 

it  Concept  D3:  Distributed  Entry  and  Retrieval. 

A 

•y  The  activity  of  the  Parts  and  Components  in  the  distributed  system  must  take 
into  account  the  effects  of  the  distributed  nature  of  the  system  on  the 


operations.  Both  the  effects  on  existing  operations  and  the  addition  of  new 
operations  must  be  considered. 

DSys3 

I  - 

I  DSys2 

I - - -  '  . . . .  . 

No  concepts  are  added  here,  only  operations. 

DSys3 . Issue( s,  d) 

I  - 

I  S3.Issue(s,  d) 

I - - 

I  s  in  Sess 

I 

I  (Site(s),  Home(s))  in  Acc 


In  order  to  Issue  information,  a  source  must  be  in  session  and  have  access 
to  its  Home. 

DSys3.Sync(c,  s,  d) - - - 

! 

I  S4.Sync(c,  s,  d) 

I - 

I  d  in  Sess 

I 

I  (Home(s),  Site(d))  in  Acc 


Synchronization  requires  that  the  Home  of  the  source  be  accessible  to  the 
destination,  but  not  that  the  Component  that  they  are  synchronizing  on  be 
accessible  to  either. 


DSys3 .Query ( s,  c,  ->d) 


s  :Sess 
c  :Comp 
d  :  DATA 


f 


(s,  c)  in  Vis 
#(View( s) (c) )  >  0 
(Site(s),  Home(s))  in  Acc 
d  =  last  (View(s)(c)) 


JS!  Query  is  not  an  essentian  operation  since  all  of  the  information  is 
■"*  available  and  therefore  all  queries  are  possible,  but  it  is  included  here  to 
indicate  and  examine  restrictions  which  should  be  included  when  queries  are 
specified.  (Note  that  if  this  were  the  only  Query,  only  the  last  Data  item 
would  have  to  be  kept  in  any  implementation  of  this  system.) 


Robust  Distributed  System. 


A  robust  distributed  system  extends  the  distributes  information  system  to 
'y-  allow  for  the  possibility  of  reconstructing  a  Part  which  happened  to  be  (at 
Home  )  at  a  Node  which  went  Down.. 


Concept  R1 :  Reconstruction  of  Information. 


S'  RbDSysl 


DSys3 


Best  :  Node  ->  (Comp  -|->  seq  DATA) 
Temp  :  FF(Part) 


•d 


Best  contained  in  View  o  inv  (home) 

All  n.  All  p(at  n),  All  c  :  #Best (n) (c) >=  #View(p)(c) 


Best  (at  each  node)  contains  the  latest  view  of  each  component  that  any  Part 
at  that  Node  has.  (The  two  constraints  are  a  precise  but  inelegant  way  of 
saying  this,  elegance  requires  reformulation  in  terms  of  more  sophisticated 


w  we:-:  <<< 


relational  operators.) 

i||  RbDSysl .TempPart(n,  p,  ->q) 

■  I  - 

I  n  :  Up;  p  :  Sess;  q  :  Name 

*  I 

I  q  not  in  Part 


q  in  Part*  and  q  in  Temp* 

View' (q)  =  Best(n)  restricted  to  im(Vis){p) 
p  not  in  Sess 1 


'■  TempPart  creates  a  temporary  Part  whose  View  is  as  good  (up  to  date)  as  any 
that  exists  on  Node  n  and  removes  P  from  being  in  session. 

i.-** 

£  RbDSysl . ReplPart (q,  p) _ 

I  q,  p  :  Part 

I  q  in  Temp 

■  ! - 

i - 

•\  I  Info'(p)  =  Info(q) 

i 

1  View1 (p)  =  View(q) 
j£J  I  Home  ’  ( p )  =  Home  ( q ) 

I  Site'(p)  =  Site(q) 

-  m  S 

I  q  not  in  Part' 

ReplPart  replaces  the  "value"  of  p  with  that  of  q  and  deletes  q  from  the 
legal  Parts. 

These  two  operations  can  be  used  together  to  reconstruct  a  Part  from 
operationally  available  implicit  replication  thus  obviating  the  need  for 
explicit  replication  whose  sole  purpose  is  for  the  reconstruction  of  Parts. 


Conclusions : 

In  our  description  of  this  experiment,  we  have  avoided  speaking  of  the 
approach  used  as  being  a  "methodology".  The  entire  intent  of  the  approach  is 
to  develop  a  useful  notational  framework  in  which  a  wide  variety  of  system 
concepts  can  be  expressed  and  in  which  one  can  reason  about  these  concepts. 


m 


We  envision  a  small  team  of  highly  trained  designers,  with  the  close 
cooperation  of  the  potential  users,  reasoning  out  the  system  design.  A 
formal  system  of  notation  would  be  used  to  express  with  mathematical 
precision  the  concepts  agreed  on  so  far,  up  for  discussion,  etc.  Having  such 
precise  documentation  would  focus  the  design,  and  its  dynamic  nature  would 
make  it  serve  as  a  growing  baseline  for  the  design.  The  fact  that  the 
notation  enables  implications  of  the  design  to  be  formulated  and  proven, 
allows  the  team  to  experiment  with  issues  that  are  usually  not  possible  to 
consider  until  the  design  has  been  implemented. 


Another  way  of  describing  "specification”  is  as  a  process  that  a  design 
team  goes  through  in  developing  a  system  specification,  not  only  for  the 
document  that  will  result.  The  process  itself  is  of  more  value  than  the 
resulting  specification  in  the  sense  that  it  requires  a  treatment  of  the 
concepts  that  must  help  to  ensure  their  consistency  and  correctness.  More 
specifically,  as  each  conceptual  module  is  formulated  and  developed,  the 
thought  process  is  anchored  and  the  discussion  focuses  on  the  appropriate 
issues.  The  resulting  document  should  not  be  dismissed.  A  specification  of 
the  desired  system  will  exist  with  a  degree  of  precision  seldom  approached. 


Appendix 


Syntax  of  "Conceptual  Module"  and  "Semantic  Operation' 


conceptCgeneric  set]- 


{  included  concept  } 


{  id:  SIGNATURE  ] 


{  invariant  descriptions  } 


(  initial  condition  } 


i 
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Mathematics  for  System  Specification 

Bernard  Sufrin 
Oxford.  1983/84 
Preface 

This  course  and  its  companions  ’'System  Specification  and  Development”,  and  "Program 
Correctness”  are  intended  to  show  you  how  to  use  mathematics  (and  in  this  course,  more 
specifically  set  theory )  in  the  design  and  development  of  computer-based  systems.  The 
principal  message  of  this  first  course  is  that  by  using  the  notation  and  reasoning  methods 
of  mathematics  it  is  possible  both  to  present  understandable  and  coherent  system 
specifications  and  to  discover  design  flaws  long  before  a  system  goes  into  production. 
Later  we  will  demonstrate  that  programs  themselves  can  be  viewed  as  mathematical  objects, 
and  show  how  it  is  possible  to  prove  whether  or  not  programs  meet  their  specifications. 

The  emphasis  in  the  first  course  is  on  learning  to  use  mathematics  es  a  tool .  so  our  initial 
presentation  of  the  basic  notation  and  reasoning  methods  will  be  intuitive  and  informal. 
Whilst  this  may  be  unfashionable  in  some  quarters,  it  is  an  approach  we  share  with  the 
teachers  of  many  forms  of  applied  mathematics.  We  introduce  the  basic  notation  by  an 
informal  characterisation  of  the  meaning  of  its  sentences.  We  extend  the  basic  notation  by 
using  its  definitional  power  to  construct  a  toolkit  which  is  powerful  enough  to  let  us  begin 
to  describe  and  reason  about  some  simple,  practical  systems.  During  this  part  of  the  course 
we  are  careful  to  present  convincing  informal  arguments  that  what  we  claim  are  theorems 
are  theorems  in  fact,  but  we  do  not  introduce  the  idea  of  a  formel  proof  until  much  later. 
By  this  time  the  need  for  rigour  will  have  become  clear,  and  we  will  spend  a  short  time  in 
outlining  the  formal  basis  for  the  notation  and  reasoning  methods  presented  earlier. 


1.  Introduction 

The  use  of  natural  language  as  a  vehicle  for  the  specification  (or  description)  of 
computer-based  systems  has  serious  limitations.  Anybody  who  has  ever  been  the  victim  of 
bad  or  inadequately  documented  software  will  confirm  that  the  manuals  which  purport  to 
describe  the  behaviour  of  a  system  never  tell  the  whole  story.  Almost  every  programmer 
who  starts  to  use  a  new  machine,  programming  language,  or  operating  system  sets  up  a 
number  of  experiments,  in  which  they  attempt  to  discover  how  it  "really”  behaves.  It  is  a 
commonplace  observation  that  computer  systems  (be  they  large  or  small)  accumulate  around 
themselves  a  body  of  folklore  —  necessary  knowledge  for  anybody  who  wishes  to  use  them 
effectively  —  and  a  number  of  "experts”  —  people  who  understand  (or  claim  to)  the 
hidden  secrets  of  the  system  because  they  have  read  _  the  source  code! 

But  even  knowledge  gained  this  way  is  transient  because  systems  never  remain  remain 
stable.  Consider,  for  example,  an  applications  program  built  using  a  database  package 
which  itself  relies  on  an  operating  system.  Because  there  is  no  definitive  and  unambiguous 
record  of  the  precise  nature  of  the  facilities  which  the  operating  system  must  provide,  the 
manufacturer's  system  programmers  may  decide  arbitrarily  that  a  certain  behaviour  is 
"accidental”,  and  may  remove  it  during  a  rewrite  --  perhaps  thereby  triggering  a  rewrite 
of  parts  of  the  database  package,  and  thence  (by  the  same  unhappy  process)  a  rewrite  of 
the  application  program.  So  an  enormous  amount  of  time,  energy  and  talent  is  wasted  in 
simply  running  to  stand  still;  an  activity  which  is  given  the  name  "maintenance”  —  as  if 
programs  were  subject  to  the  action  of  the  weather! 
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The  fact  that  natural  language  permits  a  variety  of  interpretations  to  be  made  of  a  given 
specification  is  partly  responsible  for  this  confusion.  Agreements  made  in  good  faith 
between  system  designers  and  their  clients,  turn  out  to  be  based  on  mutual  mystification 
(or  exhaustion)  rather  than  a  common  understanding  of  the  nature  of  a  requirement;  the 
same  situation  obtains  for  agreements  between  designers  and  implementers,  between  groups 
of  implementers  working  on  different  layers  of  a  system,  and  between  systems-  and 
applications-program  m  ers. 

As  well  as  wasting  hours  in  perplexing  discussions  caused  by  differing  interpretations  of 
terminology,  a  design  team  which  records  its  decisions  in  natural  language  is  often  unable 
to  foresee  serious  negative  consequences  of  bad  decisions  taken  early  in  the  life  of  a  system. 
These  often  emerge  only  after  a  great  deal  of  work  has  been  done  on  system 
implementation  —  by  which  time  it  has  become  too  costly  to  remedy  them  fully. 

The  end  result  is  what  it  has  become  fashionable  to  call  the  Software  crisis:  the  paying 
customers  rarely  get  what  they  thought  they  were  going  to  get,  the  price  is  usually  higher 
than  they  thought  they  were  going  to  pay,  and  the  end  users  suffer  more  misery  than  they 
had  dreamed  was  possible! 

It  has  long  been  conjectured  that  formalisation  can  and  should  play  a  role  in  the  process 
of  system  design  and  construction,  the  expectation  being  that  its  employment  would 
mitigate  at  least  some  of  the  problems  outlined  above.  But  except  in  certain  rather 
specialised  areas  (for  example  compiler  construction,  numerical  algorithms)  the  problems  of 
putting  this  precept  into  practise  have  come  to  be  regarded  as  almost  insurmountable  by 
the  majority  of  practising  programmers  and  designers. 

In  this  course  we  present  a  formal  languagm  —  the  language  of  set  theory  —  and  show 
how  to  use  its  notations  to  record  decisions  about  the  intended  behaviour  of 
computer-based  systems,  and  its  reasoning  methods  to  elucidate  the  consequences  of  such 
decisions.  In  order  to  illustrate  this,  we  will  apply  the  notation  to  the  description  of  a 
number  of  systems,  some  of  which  are  more  than  just  academic  examples.  Finally  we  will 
consider  formal  criteria  by  which  the  correctness  of  a  program  relative  to  its  specification 
may  be  judged. 


2.  The  Language  of  Set  Theory 


"Every  mathematician  agrees  that  every  mathematician  must  knou  some 
set  theory;  the  disagreement  begins  in  trying  to  decide  hou  much  is 
some.  ...  The  student's  task  m  learning  set  theory  is  to  steep  himself 
in  unfamiliar  but  essentially  shallow  generalities  until  they  become 
so  familiar  that  they  can  be  used  uith  almost  no  conscious  effort.  In 
other  uords.  general  set  theory  is  pretty  trivial  stuff  really,  but  if 
you  uant  to  be  a  mathematician  you  need  some,  end  here  it  is ;  read  it, 
absorb  it.  and  forget  it." 

from  che  introduction  to  “da/ve  Set  Theory ”  by  Paul  R.  Halmos 


"far  the  logician,  a  mam  virtue  of  a  theory  is  that  it  be  concise,  so  as 
to  be  easier  to  study  and  characterise ;  notation  is  typically  devoid  of 
all  intuit/ve  content,  so  that  a  sentence  util  not  be  confused  mth  its 
meenmg.  It  is  common  that  intuitively  evident  sentences  are  quite 
difficult  to  prove  m  such  theories. 

far  the  computer  scientist,  it  is  more  important  that  a  theory  be  easy 
to  use.  Proofs  of  evident  sentences  uithm  the  theory  should  be  easy 
to  discover,  and  possibly  to  automate .  and  should  reflect  the  intuition 
behind  them* 

from  "The  Logical  Basis  for  Computer  Programming”  by  Zohar  Manna 
and  Richard  Maldingar. 

2.1  Introduction 

The  study  of  logic  (and  later  of  set  theory)  arose  out  of  the  desire  of  mathematicians  to 
produce  rules  which  enabled  them  to  say  which  arguments  were  valid  and  which  were  not. 
In  view  of  its  importance  to  mathematicians,  it  may  come  as  rather  a  shock  to  a 
Computer  Scientist  to  discover  that  despite  the  fact  that  it  has  been  studied  as  a  topic  in 
its  own  right  for  at  least  a  century,  mathematicians  have  not  yet  agreed  upon  a  concrete 
syntax  for  the  language  of  set  theory!  If  you  understand  that  concrete  syntax  isn’t  really 
very  important  you  may  be  more  surprised  to  learn  that  they  haven’t  agreed  on  an 
abstract  syntax  or  a  semantics  (more  precisely  an  axiom atisation)  either. 

If  we  want  to  use  the  language  of  set  theory  as  a  means  of  communicating  ideas,  then 
we’re  obliged  to  choose  an  existing  variant  or  to  invent  one  of  our  own.  It  turns  out  -- 
though  it  might  not  have  —  that  it  doesn’t  really  matter  which  variant  we  choose;  the 
differences  between  the  rival  axiom atisations  will  not  drastically  affect  the  way  we  work 
or  the  style  of  reasoning  we  are  able  to  use.  This  is  because  the  differences  between 
axiom  atisations  only  become  apparent  in  the  curious  realms  of  the  transfinite,  and 
computation  is  done  in  the  realm  of  the  finite  (or  at  worst  the  countably  infinite). 

Apart  from  a  little  syntactic  sugaring,  the  language  presented  in  the  first  part  of  the 
course  follows  that  presented  in  the  first  part  of  T  Abr/al  1  —  to  whom  those  concerned 
with  a  more  formal  approach  may  turn.  It  will  later  become  apparent  to  cognoscenti  that 
there  are  differences  with  that  language  which  are  not  merely  cosmetic  For  the  moment, 
though,  those  differences  may  not  be  perceived,  and  in  any  case  can  safely  be  ignored. 
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Other  informal  presentations  will  be  found  in  C  Halmas 1 .  and  Cones  J . 

If  we  were  programmers  studying  a  programming  language  with  the  intention  of 
programming  in  it  we  might  examine  it  in  terms  of  expressions,  declarations  and 
commands  and  their  respective  meanings,  and  try  to  discover  what  it  had  in  common  with 
the  languages  we  already  knew.  We’d  also  try  to  discover  the  purpose  of  any  glaring 
unortbodoxies.  As  programmers  and  mathematicians  studying  one  dialect  of  the  language 
of  set  theory  with  the  intention  of  writing  specifications  in  it,  we  will  find  it  useful  to 
begin  by  examining  its  four  interrelated  sublanguages,  namely  the  language  of  terms,  the 
language  of  predicates,  the  language  of  definitions,  and  the  language  of  theorems  In 
subsequent  sections  we  will  show  how  the  languages  are  extended. 

Assuming  some  familiarity  with  the  ideas,  vocabulary  and  symbolism  of  logic  and  set 
theory,  we  will  try  to  give  a  general  idea  of  the  flavour  of  these  component  languages  by 
means  of  a  few  simple  examples.  After  reading  these  you  should  be  able  to  point  out  the 
main  differences  between  our  notation  and  the  “standard’*  notations.  Understanding  our 
reasons  for  introducing  the  differences  will  certainly  take  longer. 

2.2  Term  language 

A  term  is  a  phrase  of  the  language  which  corresponds  intuitively  to  a  set  or  to  an 
element  of  a  set  Examples  of  sets  are  a  pack  of  wolves,  a  bunch  of  grapes,  a  flock  of 
pigeons  or  a  collection  of  books.  An  element  of  a  set  may  be  a  wolf,  a  grape  or  a 
pigeon,  a  book,  a  number,  or  a  function.  A  set  may  have  elements  which  are  other  sets  — 

for  example  in  classical  geometry  a  line  is  a  set  of  points  so  the  set  of  lines  in  a  plane  is 

an  example  of  a  set  of  sets. 

The  simplest  kind  of  term  is  a  name,  for  example: 

N 

Bernard 

The  language  of  definitions  (which  we  discuss  later)  is  used  for  introducing  new  terms  into 
a  document  written  in  the  language  of  set  theory,  and  giving  them  meaning.  In  order  to 
simplify  what  follows,  we  will  assume  that  N  has  already  been  defined  in  such  a  way  that 
it  denotes  the  set  of  Natural  Numbers  (nonnegative  integers). 

One  way  to  specify  a  (finite)  set  of  Numbers  is  to  write  down  its  elements  one  by  one  — 

this  is  often  called  an  extensions!  definition  or  specification.  For  example 

(1.  2.  3.  5.  7) 

It  is  obviously  out  of  the  question  to  give  extensional  specifications  for  sets  (even  finite 
sets)  above  a  certain  size  We  cannot,  for  example,  write  down  ail  the  elements  of  the  set 
of  prime  numbers.  Another  kind  of  term  is  used  to  denote  such  large  sets,  and  an  example 
of  this  kind  of  term  is: 

(  n:N  |  (divisors  n)  =  (1,  n>  > 

which  reads  "the  set  of  natural  numbers  n  whose  divisors  are  l  and  n".  This  style  of  set 
description  is  called  comprehensive,  it  is  used  to  specify  subsets  of  a  certain  set  by 
giving  the  characteristic  properties  of  their  elements. 

The  first  part  of  such  a  term  is  a  signature ,  in  the  case  of  our  example: 


which  introduces  a  neu  variable  n  which  may  take  values  from  the  set  of  natural 
numbers  (N)  and  whose  scope  is  the  second  part  of  the  term,  namely  the  predicate 

(divisors  n)  =  (1,  n> 

In  fact  it  doesn’t  matter  what  the  name  of  the  variable  is:  a  number  is  in  the  set  denoted 
by  this  term  exactly  when  the  divisors  of  that  number  are  1  and  the  number  itself;  indeed 
the  same  set  can  be  denoted  by: 

I  i:N  |  (divisors  a)  =  (l.  a>  ) 

or  by: 

(  cabbage  :N  |  (divisors  cabbage)  =  (1,  cabbage)  > 

Yet  another  way  to  read  this  term  is:  "the  set,  each  of  whose  elements  is  a  Number  whose 
divisors  are  1  and  itself”. 


2J  Predicate  language 

A  predicate  is  a  phrase  of  the  language  which  corresponds  to  a  statement  (about  sets 
and/or  elements)  which  may  be  true  or  false.  For  example:  ”x  is  smaller  than  4”,  "There  is 
no  number  which  is  larger  than  all  the  prime  numbers”,  "All  prime  numbers  are  of  the 
form  n*+m*+l  for  some  numbers  n  and  m”,  "The  inverse  of  the  successor  function  is  a 
f  unction". 

A  predicate  is  either  a  primitive  predicate  or  is  constructed  from  simpler  predicates  by 
means  of  propositional  connectives  which  are  denoted  by  the  signs: 

...  and  ... 

...  or  ... 
not  ... 

1/  ...  than  ... 

. . .  exactly  uhan  . . . 

Supposing  that  P  stands  for  a  predicate  which  corresponds  to  "There  is  no  number  which 
is  larger  than  all  the  prime  numbers”,  and  that  Q  stands  for  a  predicate  which  corresponds 
to  "All  prime  numbers  are  of  the  form  then  the  predicate: 

p  a  a  .  (  Pii 

corresponds  to  the  statement  "There  is  no  number  which  is  larger  than  all  the  prime 
numbers  and  all  prime  numbers  are  of  the  form  The  predicate 


P  V  Q  .  (PZ.) 

corresponds  to  the  statement  "There  is  no  number  which  is  larger  than  all  the  prime 
numbers,  or  all  prime  numbers  are  of  the  form 


By  definition  in  order  to  prase  the  truth  of  the  first  of  these  predicates  (PI),  of  course, 
we  would  have  to  prove  the  truth  of  both  its  constituents,  that  is  P  and  Q.  (If  >ou  think 
you  can  prove  Q  then  come  and  see  me).  By  definition,  in  order  to  prove  the  truth  of  the 
second  predicate  (P2),  all  that  is  needed  is  to  prove  one  of  its  constituents;  in  other  words 
the  symbol  which  we  pronounce  "or"  corresponds  to  the  idea  "either  _  or  _  or  both”. 

It  turns  out  that  the  propositional  connectives  can  all  be  defined  in  terms  of  not  and  and 
by  syntactic  equivalence,  thus  if  P  and  Q  are  predicates  we  have: 

p  v  q  a  *  ('P  «  *0) 
p  — »  Q  a  -p  v  q 

The  "exactly  when"  relationship  between  two  predicates,  P  and  Q  (sometimes  read  "P  if  and 
only  if  Q”)  is  written 

p  •*  a 

it  is  the  conjunction  (and)  of  the  predicates  which  correspond  to  "If  P  then  Q”  and  "If  Q 
then  P",  that  is 

p*»a  «  p-*q  a  a-*p 

Evidently  one  strategy  for  proving  an  "exactly  when"  predicate  would  be  to  prove  both  its 
"if  -  then  components. 

It  is  very  important  to  understand  that  the  truth  of  the  statement  "if  P  then  Q"  does  not 
guarantee  the  truth  of  the  statement  "if  not  P  then  not  Q”.  You  might  be  able  to 
convince  yourself  of  this  by  considering,  for  example,  the  "real  life”  fact  "//  it  is  raining 
then  the  roof  is  net*',  if  "it  is  not  raining"  is  the  only  fact  we  know,  then  we  still 
can’t  conclude  anything  about  the  wetness  of  the  roof  (it  may  just  have  stopped  raining,  or 
a  flock  of  herons  with  bladder  trouble  may  have  just  flown  over).  Perhaps  it  would  be 
easier  to  convince  oneself  of  this  if  instead  of  saying  "if  P  then  Q"  we  said  "Q  must  hold 
whenever  P  holds". 

The  first  primitive  predicate  we  will  introduce  is  the  one  which  corresponds  to  the 
concept  of  of  membership  or  belonging.  If  the  element  x  belongs  to  the  set  S  then  the 
predicate 

x  €  s 

is  true;  otherwise  the  predicate  is  false.  For  example, 

3  €  primes 
is  true,  but 

2345878  «  priaaa 

is  false. 

Next  we  introduce  the  predicate  which  corresponds  to  the  eouahty  relationship  between 
sets:  two  sets  are  said  to  be  equal  if  they  have  exactly  the  same  elements.  If  S  and  T 
denote  subsets  of  a  set  which  have  exactly  the  same  elements  then  we  write  S=T. 


The  third  predicate  to  be  introduced  is  the  "is  a  subset  of”  predicate:  if  every  element  of  a 
set  S  is  also  an  element  of  the  set  T  then  we  say  that  S  is  a  subset  of  T  and  write: 

S  s  t 

If  S  is  a  subset  of  T  which  does  not  have  exactly  the  same  elements  as  T  then  we  say  it  is 
a  proper  subset  of  T  and  write: 

S  c  T 


Later  in  this  section  we  will  formalise  the  connection  between  these  three  kinds  of 
predicate. 

The  predicate  which  corresponds  to  the  notion  "all  -  have  the  property  is  written  with 
a  symbol  which  frightens  some  people.  For  example,  the  statement  "all  numbers  when 
added  to  themselves  produce  a  prime  number”  is  expressed  as  the  predicate: 

V  n:N  .  (n+n)*priaea 

Of  course  this  predicate  —  and  the  statement  to  which  it  corresponds  —  is  false,  but  that 
doesn’t  mean  we  can’t  write  it  down. 

Here  are  some  more  examples: 

(a+1  ■  b+1 ) 

divisors  n  a  (1,  5.  7) 
n  e  prises 

(  n:H  |  (divisors  nl  «  <1,  n)  )  M) 

3  n:N  .  (divisors  n)  *  <1,  n> 
v  a:N;  b:N  .  (a+t  *  b-i) 

The  last  predicate  —  which  formalises  the  statement  that  for  all  natural  numbers  a  and  b, 
a+l  is  equal  to  b-1  —  is  false,  whereas  the  first  three  may  be  true  or  false  depending  on 
the  values  of  n,  a,  and  b  —  we  need  to  know  more  about  these  values  in  order  to  discover 
whether  or  not  the  predicates  are  true.  There  are  many  situations  in  which  it  may  not  be 
possible  to  demonstrate  the  truth  or  falsity  of  a  predicate. 

The  alert  reader  will  have  noticed  that  the  predicates  above  aren’t  independent  of  each 
other.  The  penultimate  predicate  —  which  is  also  written  with  a  symbol  which  some 
people  claim  to  be  frightened  of  —  may  be  read  "there  is  a  natural  number,  n,  which  has 
divisors  1  and  n”.  It  is  true  exactly  when  the  fourth  predicate 

(  n: M  |  (divisors  n)  *  (1,  n>  )  *  {) 

which  may  be  read  "the  set,  each  of  whose  elements  is  a  Number  whose  divisors  are  _  is 
not  the  empty  set”  is  true  (and  false  exactly  when  the  fourth  predicate  is  false). 

We  can  use  "exactly  when"  to  encapsulate  the  connection  between  the  subset  relationship 
and  a  "for  all  predicate  more  formally.  The  following  predicate  is  always  true  for  any 
sets  S  and  T: 


We  can  do  the  same  for  equality  of  sets;  the  following  predicate  is  always  true  for  any 
sets  S  and  T: 


UV  x:S  .  x«T)  *  (V  x: T  .  x«S))  ~  <S=T) 

Since  “exactly  when*  is  a  transitive  relationship  (that  is  for  any  predicates  P,  Q  and  R,  if 
P  holds  "exactly  when"  Q  holds,  and  if  Q  holds  "exactly  when"  R  holds,  then  P  holds 
"exactly  when”  R  holds)  the  following  connection  between  the  subset  relation  and  the 
equality  relation  follows  from  the  two  connections  just  outlined: 

US  C  T)  A  (T  C  S))  (S=T) 

Finally,  we  can  express  a  general  relationship  between  statements  of  the  form  "there  is  a  _ 
for  which  the  property  -  holds"  and  "all  -  have  the  property  namely  that  for  all  sets 
S  and  predicates,  P 

(V  x:S  .  P)  •*  *(  3  x: S  .  'P  ) 

In  other  words  P  holds  for  all  elements  of  S  exactly  when  there  is  no  element  of  S  for 
which  the  negation  of  P  holds. 


2.4  Definition  language  —  Syntactic  Equivalences 

A  simp  la  syntactic  ecunsalenca  is  a  phrase  of  the  language  which  associates  a  name 
with  a  term.  For  example,  the  following  definition  associates  the  name  priaes  with  a 
term  denoting  the  set  of  all  prime  numbers. 

prises  a  {  n;H  |  divisors  n  ■  (1,  n)  ) 

It  signifies  that  priaes  is  a  shorthand  for  the  term  on  the  right  hand  side  of  the  a  sign. 
For  example,  if  we  are  asked  to  prove  that 

3  «  priaes 

then  the  first  thing  we  do  is  to  substitute  the  definition  of  priaes  for  priaes  itself,  and 
try  to  prove  that: 

3  «  (  n:N  |  ...  ) 

which  we  will  probably  do  by  trying  to  prove  that  the  predicate  _  holds  when  3  is 
substituted  systematically  for  n  in  it. 

Another  form  of  the  same  definition  is: 

rriaes _ ( 

{  n:N  I  divisors  n  =  (1,  n)  > 


It  means  exactly  the  same  as  the  "a"  form. 

More  complicated  forms  of  syntactic  equivalence  will  be  introduced  as  the  need  arises. 
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2.5  Theorem  language 

Stripped  of  its  prose  any  text  in  the  language  of  set  theory  consists  at  the  "top  level**  of 
several  definitions,  followed  by  several  theorems.  A  theorem  is  a  statement  about  the 
definitions;  it  asserts  that  a  certain  predicate  can  be  (has  been)  proved  to  be  true  from  the 
definitions  themselves  and  the  rules  of  reasoning  of  the  language  of  set  theory. 

The  simplest  form  of  theorem  is  written  as  a  turnstile  sign  followed  by  a  predicate: 

*-  Predicate 

The  following  theorem,  for  example,  is  tantamount  to  an  assertion  that  we  have  proved 
that  3  is  an  element  of  the  set  denoted  by  the  name  priaes. 

*-  3  «  primes 

Of  course  have  not  yet  introduced  the  rules  of  reasoning  so  it  is  not  strictly  possible  for 
our  readers  to  prove  this  theorem.  What  is  possible  is  to  argue  informally  from  an 
intuitive  knowledge  of  the  properties  of  sets  and  of  the  divisors  function  but  this 

informal  argument  should  not  be  mistaken  for  formal  proof.  Indeed  there  is  another 
problem:  we  have  yet  to  write  down  a  definition  for  "divisors*,  any  informal  reasoning 
must  at  present  be  based  on  the  fact  that  the  name  "divisors*  suggests  that  the  function  in 

question  maps  a  number  into  the  complete  set  of  its  divisors  —  which  may  not  be  sol 

We  will  say  more  about  the  rules  of  reasoning  later.  For  the  moment  it  is  sufficient  to 
understand  that  a  theorem  is  not  a  predicate,  nor  may  a  theorem  be  written  within  a 
predicate;  for  example  the  following  pseudo-set-theoretical  text  is  not  part  of  the 

language  of  set  theory. 

WRONG  4  «  (divisors  n)  -•  (  *-  n  *  prises  )  WRONG 


2.6  Definition  language  —  Signatures 
2.6J  —  Variables 

In  order  to  introduce  a  new  variable  we  must  first  indicate  the  set  of  values  over  which 
the  variable  is  permitted  to  range;  we  do  so  by  means  of  a  signature.  For  example,  the 
following  signatures  associate  respectively  n  with  the  set  N  ( natural  number )  and  a  and  b 
with  the  set  sequences  of  H 


n:  N 

a,  b:  ssq  N; 

The  phrases  within  which  signatures  introduce  variables  include  the  predicates 
v  Signature  .  Predicate 
3  Signature  .  Predicate 
and  the  terms 

(  Signature  I  Predicate  ) 

X  Signature  I  Predicate  .  Term 


a 


9 


The  signs 


I 


N 


.V 


\\ 

9 


'6 


3.  » 

are  called  "quantifiers’  in  classical  logic.  When  we  use  this  word  we  also  include  the  signs: 

X.  (  ...  I  ...  ) 

We  will  say  more  about  X  later. 

The  scape  of  the  association  between  name  and  type  (that  is  those  parts  of  the  text  from 
which  the  association  is  visible)  for  variables  introduced  this  way  is  the  text  of  the 
Predicate,  (or  in  the  case  of  the  X-term  the  text  of  the  Predicate  and  the  Term)  except 
where  the  association  is  temporarily  made  invisible  by  an  intervening  signature  for  the 
same  name. 

For  example  in  the  following  predicate 
V  a: LECT  . 

3  n:CAR  .  pred,  *  (a:N  I  pred,)  =  () 

the  association  a:  LECT  is  "visible’  in  predl .  tha  association  n:  CAR  is  visible  in  predl  and 
prod2.  and  the  association  a:N  is  visible  in  prad2. 

2.6.2  —  Constants 

In  order  to  introduce  a  new  constant  into  a  piece  of  mathematical  discourse,  we  also  give 
a  signature  for  it;  this  time  at  the  "top  level".  The  signature  may  be  associated  a  predicate 
which  constrains  its  value  in  some  way.  Predicates  which  constrain  constants  introduced  in 
this  way  are  sometimes  called  axioms. 

For  example  this  is  how  to  introduce  a  constant  (of  type)  Number,  whose  value  we  require 
to  be  between  seven  and  nineteen,  but  about  which  we  wish  to  be  no  more  specific 


processor  ape  mode:  N 


7<processorspernode<19 


The  double  horizontal  line  has  no  significance,  except  that  it  serves  as  typographical 
emphasis  that  the  signature  appears  at  the  top  level.  Likewise  the  short  horizontal  line 
simply  separates  the  signature  from  the  predicates  with  which  it  is  associated,  and  the  long 
single  horizontal  line  emphasises  the  end  of  the  predicates. 

The  following  signature  and  its  associated  predicate  introduce  a  constant  function  from 
numbers  to  numbers,  named  foo,  which  maps  every  number  into  its  square: 


£00 : 

- 1 

N  — *  N 

*  n:  N 

.  £00  n  =  n  *  n 

Of  course  we  haven’t  explained  properly  what  we  mean  by  the  sign  — *  or  by  the  word 
function  '  We  will  do  so  later. 
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A  constant  defined  in  this  way  is  visible  throughout  the  whole  of  the  remaining 
"mathematical  discourse",  except  for  those  places  where  variables  with  the  same  name  are 
visible. 


2.7  Set  Comprehension  Revisited 

Mathematicians  sometimes  use  another  form  of  comprehensive  specification  to  denote  the 
set  of  all  things  "of  a  certain  kind”,  for  example: 

{  n:N  .  nJ  ) 

denotes  the  set  of  all  things  of  the  form 


where  n  ranges  over  the  natural  numbers.  Another  example  is 


{  a,  n:N  |  ma+na<44  .  na-aa  > 


which  denotes  the  set  of  ail  things  of  the  form 


where  a  and  n  range  over  the  numbers  in  such  a  way  that  the  sum  of  their  squares  is  less 
than  44. 

In  fact  the  general  form  of  a  comprehensive  set  specification  is: 

(  Signature  I  Predicate  .  Tera  > 

There  are  a  number  of  special  cases  of  this  form  which  can  be  abbreviated.  If  the 
Predicate  doesn’t  constrain  the  variables  of  the  signature  (in  other  words  if  it  is 
identically  true)  then  we  leave  it  out  and  write  the  comprehension  as: 

(  Signature  .  Tera  ) 

If  the  Signature  introduces  a  single  variable  and  the  Tera  /s  that  variable  then  we  leave 
out  the  Tera  and  and  write  the  comprehension  as: 

(  Signature  1  Predicate  > 

This  form  of  abbreviation  will  later  be  generalised 

If  we  leave  out  both  Tera  and  Predicate  we  just  get  the  degenerate  case: 

(  Signature  ) 

An  example  of  this  is 

(  x:X  > 


which  is  an  abbreviation  for 


I 


II 


{  x:  x  i  true  .  x  > 


which  is  the  set  of  elements  x  of  X  for  which  the  predicate  true  holds.  Of  course  this  is 
just  the  set 

X 

itself. 

Some  mathematicians  use  one  or  both  of  the  syntactic  forms: 

<  Tara  |  Signature  |  Predicate  > 

(  Term  I  Signature  > 

to  denote  set  comprehension. 

2.8  Structured  Types:  Part  1 

We  have  shown  how  to  specify  subsets  of  a  given  set  using  extensional  and 
comprehensive  specifications,  but  these  (sub)-sets  can  never  have  more  in  them  than  the 
original  set.  In  this  section  we  introduce  two  means  of  constructing  "bigger'*  sets  from 
given  sets;  the  remaining  method  (tree-constructions)  will  be  introduced  later. 

2.8.1  Cross-Products  —  Sets  of  Tuples 

If  T1  and  T2  are  both  sets,  then  the  term 

T,  x  I, 

denotes  another  set,  namely  the  set  of  two-tuples  (ordered  pairs)  whose  first  elements  are 
drvwn  from  Tl  and  whose  second  elements  are  drawn  from  T2.  This  set  is  sometimes 
called  the  product  or  cross-product  of  Tl  and  T2. 

The  ordered  pair  whose  first  element  is  a  and  whose  second  element  is  b  is  written 

(a,  b) 

If  we  have  somewhere  defined 
LECT  a  {  BS,  TH  > 

CAR  a  <  RVR360V.  PVIM95V.  A420G8H  > 
then  the  term 

LECT*CAR 

denotes  the  set  of  ordered  pairs 

(  (BS.  RVR360V).  (BS.  PVM495V) .  (BS.  A420GSH) , 

(TH.  RVR360W) .  (TH.  PVM495V) ,  (TH,  A420GBH)  > 

This  set  has  six  elements  —  the  arithmetical  product  of  the  number  of  elements  in  LECT 
and  the  number  of  elements  in  CAR,  hence  the  name  cross-product. 


Another  term  denotes  the  same  set,  namely 


(  1 : LECT :  a: CAR  .  (1,  a)  ) 


It  can  be  read  as  "the  set  of  all  ordered  pairs  (l.a)  where  1  is  an  element  of  LECT  and  a 
is  an  element  of  CAR.  *  By  generalising  the  abbreviation  introduced  in  section  2.7  we  can 
rewrite  this  term  as 

{  1 : LECT ;  a: CAR  } 

Subsets  of  the  cross  product  are  denoted  by  terms  of  the  form: 


<  1: LECT:  a: CAR  I  Predicate  .  (1.  a)  > 

which  (again  generalising  the  abbreviation  of  section  2.7)  can  be  shortened  to 

<  1: LECT:  a: CAR  I  Predicate  > 

We  can  generalise  the  notation  for  two-tuples  to  that  for  n-tupies  by  using  the  following 
syntactic  equivalences: 

I,  *  I,  x  t,  a  I,  x  (I,  x  Ta) 


(x,  y,  ...  z)  a  tx.  (y.  ...  z)) 


For  example: 


LECTxCARx 11983,  1902.  1901) 


denotes  the  set  of  triples 


<  1: LECT:  a:CAR:  y:N  |  y<(1903.  1902,  1901)  .  (1.  a.  y)  ) 


2.8.2  Power  Sets  —  Sets  of  Subsets 

The  pouerset  of  a  given  set,  S  say,  denoted  by  the  term 


is  the  set  whose  elements  are  the  subsets  of  S.  For  example  the  power  set  of  LECT  is 

(  ().  <BS>,  <TH)  IBS,  TH>  > 

Notice  that  the  number  of  elements  of  P  S  is  2  to  the  pouer  of  the  number  of  elements 
of  S  (hence  the  name). 

The  term  <)  denotes  the  empty  set,  whose  properties  with  respect  to  any  set  X  can  be 
summed  up  by  the  theorem: 

-  V  x:  X  .  x<<  ) 


In  other  words  —  no  member  of  any  set  /s  a  member  o/  the  empty  set. 


What  is  more,  the  properties  of  an  empty  subset  SS  of  a  set  X  with  respect  to  any 
predicate  P  can  be  summed  up  by: 

-  V  SS : P  X  .  SS*<  >  -•  (V  x: SS  .  P) 

In  other  words  any  predicate  about  all  the  elements  of  an  empty  set  is  true ;  of  course 
since  there  are  no  such  elements  this  fact  is  not  too  useful! 

Notice  that  the  power  set  of  the  empty  set  has  exactly  one  element,  namely  the  empty  set 
itself;  that  is: 

*-  CP  (})  a  <  (}  ) 

This  should  demonstrate  that  it  is  important  to  be  very  clear  about  the  distinction  between 
a  set  with  no  elements  and  a  set  whose  single  element  is  a  set  with  no  elements  (if  you 
don’t  like  this,  then  reflea  on  the  difference  between  an  empty  tea  packet,  and  a  cupboard 
with  only  an  empty  tea  packet  inside). 

The  power  set  of  N  is  very  large  (so  big  that  its  size  isn’t  expressible  as  a  Natural  number). 
Here  is  one  way  of  specifying  a  constant  whose  value  is  a  single  element  (/«  a  set  of 
numbers)  of  that  huge  set- 


Odd  is  the  set  of  numbers  of  the  form  n+1  for  even  numbers  n. 

As  an  exercise  try  specifying  Even  in  the  style  we  used  for  specifying  Odd  and  specifying 
Odd  in  the  style  we  used  for  specifying  Even. 


2.8.3  Finite  Subsets 

The  idea  of  a  finite  set  is  quite  familiar  to  us,  but  it's  surprisingly  hard  to  find  a  simple 
formal  definition.  Informally,  the  finite  sets  are  those  whose  elements  we  can  "count”. 

Notation:  If  X  is  a  set,  then  we  write 

F  X 

to  denote  the  set  of  finite  subsets  of  X.  Evidently  if  X  is  itself  finite  we  have: 
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F  X  =  P  X 


It  can  also  be  proved  that 

>-  F  X  »  ()  U  I  x:X;  so: F  X  .  (x)Uss  > 


in  other  words,  the  set  of  finite  subsets  of  X  contains  the  empty  set  and  those  made  by 
"adding  a  single  element  of  X  to  a  finite  subset  of  X”. 

The  number  of  elements  in  a  finite  set,  S,  sometimes  called  its  cardinality,  or  sure,  is 
written  »S  .  The  important  properties  of  the  *  operator,  which  reflect  the  fact  that  finite 
sets  can  be  built  up  by  adding  elements  "one  by  one"  to  the  empty  set,  are: 

*0=0 

V  S:F  X  .  y  x: X  .  x*S  —  *( { x)US) =i+#S 
If  T  does  not  denote  a  set,  then  the  term  *T  has  no  meaning. 

This  concludes  our  introduction  to  the  flavour  of  the  sublanguages  of  the  language  of  set 
theory.  By  now  you  should  understand  the  ideas  to  which  terms  and  predicates  correspond, 
what  a  signature  is,  how  to  specify  a  subset  of  a  given  set,  and  how  to  specify  sets  of  sets 
and  sets  of  tuples. 


13 


3:  The  Language  of  Relations  and  Functions 


In  this  section  of  the  course,  we  show  how  the  basic  language  of  set  theory  is  extended  to 
include  notations  which  allow  us  to  describe  relations  and  functions. 


3.1  Binary  Relations 

You  are  already  familiar  with  the  concept  of  a  binary  relation  —  for  example  in 
mathematics  the  relations  "is  less  than”,  "is  a  subset  of*  or  in  law  "owns  a  car  whose 
registration  number  is".  In  the  language  of  set  theory,  binary  relations  are  considered  to  be 
sets  of  pairs. 

For  example,  the  "less  than"  relation  on  the  natural  numbers  is  the  set  of  pairs 
{  i : N;  j:N  |  (3  k:N  .  i*k-j  a  )c*0)  } 

(though  we  wouldn’t  define  it  in  this  way). 

Notation:  If  R  is  a  binary  relation  between  elements  of  A  and  of  B,  and  if  a:  A  and  b:B 
then  the  predicate 

a  R  b 

is  syntactically  equivalent  to  the  predicate 
(a,b)  e  R 

Sometimes  we  write  a  maps  to  b  under  R  or  R  maps  a  to  b;  using  this  terminology,  of 
course,  we  see  that  "<"  maps  (for  example)  3  to  every  number  bigger  than  three. 

Relations  can  be  finite,  for  example  suppose  that  OWNER  is  the  set  of  all  potential  car 
owners,  that  REG  is  the  set  of  car  registrations,  and  that  MAKER  is  the  set  of  car 
manufacturers.  Without  concerning  ourselves  with  the  internal  structure  of  these  sets  let's 
also  suppose  that  we  have  certain  distinguished  constants,  namely 

TH.  JS.  BS.  RB.  IS:  OWNER 

Ford,  Bentley,  Renault,  Morris,  Datsun:  MAKER 
a420gbh,  rwr360w,  pv«495,  is400p,  al90:  REG 

Then  we  could  specify  relations  owns  and  made  respectively: 

(  (TH.  a420gbh),  (BS,  rwr360w) .  (BS.  pv*495),  (IS.  is400p)  > 

(  (Renault,  a420gbh) ,  (Morris,  rvr380w) 

(Morris.  pv»495),  (Datsun,  is400p) ,  (Bentley,  al90)  } 

In  which  case  the  following  predicates  would  be  true 

TH  owns  a420gbh 
BS  owns  rwr360w 

Morris  made  rwr360w 

whereas  these  are  false 
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BS  owns  is400p 

TH  own*  pva495 

Bentley  aade  pvn495 

Ford  Bade  a420gbh 

It  is  customary  to  use  the  following  syntactic  sugar  for  the  the  pairs  which  make  up  a 
relation: 

a<— »b  a  (a.b) 
so  own*  would  be  written 

{  TH»— *a420gbh,  BS»-+rwr3S0w.  BS>->pv»495,  ISi— *ia400p  ) 
and  "<”  could  be  written 

{  i:  N;  j:N  |  (3  k:H  ...  )  .  i*-»j  ) 

Notation:  Given  two  sets  X  and  Y  the  set  of  relations  between  X  and  Y  —  which  is 

denoted  X«-*Y  —  is  the  power  set  of  their  cross  product.  More  formally: 

CX.YI  X«-»Y  a  P(X*Y) 

This  is  a  more  complicated  form  of  syntactic  equivalence  which  comes  in  two  parts;  the 

first  part  reads  'given  two  sets  X  and  Y”  and  the  second  defines  the  left  hand  term  to  be 

syntactically  equivalent  to  the  right  hand  term.  We  could  also  have  written  it  as 


3.2  Domain  and  Range  of  a  Relation 

Given  a  relation 

R:  X«-*Y 

the  domain  of  R  —  written  doa  R  —  is  the  set  of  all  elements  of  X  which  R  relates  to  at 
least  one  element  of  Y.  In  other  words: 

doa  R  =  {  x:X  I  (3  y:Y  .  x  R  y)  > 

The  range  of  R  —  written  ran  R  —  is  the  set  of  all  elements  of  Y  which  are  related  by  R 

to  at  least  one  element  of  X,  that  is: 

ran  R  =  (  y:Y  I  (3  x:X  .  x  R  y)  > 

A  relation  whose  domain  and  range  are  subsets  of  the  same  set  is  called  a  homogeneous 
relation.  The  empty  relation  0  is  just  the  empty  set  of  pairs.  Its  domain  and  range  are 

empty;  it  isn’t  too  interesting  (to  be  more  precise  it's  about  as  interesting  as  the  number  0 

or  the  empty  set). 
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3.3  Partial  Functions 

Functions  are  amongst  the  most  basic  tools  of  mathematicians  and  computer  programmers. 
As  programmers  you  may  be  used  to  thinking  of  functions  as  "recipes  for  computing” 
certain  quantities;  in  the  language  of  set  theory  (indeed  in  the  whole  of  mathematics  apart 
from  computation)  it  is  convenient  to  treat  functions  more  abstractly  than  this,  namely  as 
special  kinds  of  relation 

A  relation  R  is  called  a  partial  function  if  it  maps  each  element  of  its  domain  to 
exactly  one  element  of  its  range.  More  formally: 

X~Y  1X.YJ _ , 

{  R:X«-*Y  1  (  V  x:X;  yt,ya:Y  .  (xRy,  a  xRya>  -*  y,=ya  )  > 


The  so-called  total  functions  from  a  set  X  are  defined  by 

_  X-*Y  CX.Y1  _ 

{  f:X-»Y  |  do*  f  *  X  > 


In  referring  to  a  function  as  total  it  is  important  to  say  from  uhat  sat  it  is  total.  This  is 
because  in  general  we  can  derive  many  "total”  functions  from  a  partial  function  —  one  for 
each  subset  of  its  domain  More  formally: 

V  £ :  X-**Y  . 

V  S:P  X  . 

Sc ( doe  £)  ^  (  x;X;  y:Y  I  x«S  A  x  £  y  >«(S-*Y) 

We.  use  the  phrase  proper  relation  to  describe  a  relation  which  is  not  functional.  (For 
example  *<”). 

Notation:  if  F:X*-*Y  is  a  function,  and  if  x  is  an  element  of  the  domain  of  F,  then  the 
term 

F  x 

means  the  unique  y  in  Y  such  that  xFy.  If,  on  the  other  hand,  x  is  not  an  element  of  the 
domain  of  F  then  we  cannot  conclude  anything  about  that  term. 

For  example,  consider  the  "unsquare”  function 

unaq  =  (  x:M  .  x*  *-*  x  ) 


The  term 


unsq  4 

means  2,  because  2  is  the  unique  number  satisfying  4  unsq  x.  On  the  other  hand,  the 
term  unsq  5  has  no  meaning  (or  to  be  more  precise,  cannot  be  reasoned  about  any 

f  urther  > . 

Infix  Notation:  if  F-.  (X  *  Y)*-*  Z  is  a  function,  and  if  x:X  and  y:Y  then  the 
following  syntactic  equivalence  holds 

x  F  y  a  F(x, y) 
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w'. 


.'VrJVrW  --J  r.  r.  w-„ 


At  first  sight  this  appears  to  be  syntactically  ambiguous,  since  if  F  is  a  function  it  is  also 
a  relation,  and  we  already  defined  the  predicate 

a  8  b  a  (a,b)eR 

The  apparent  ambiguity  may  be  resolved  by  inspecting  the  "shape"  of  the  function  and  of 
its  operands.  To  be  more  precise,  if  x,  y,  z.  and  F  are  introduced  by 

X:X 

y:Y 

z  •  2 

F:X>Y  -**  2 
then  the  phrase 

(x  F  y) 

is  a  term  of  type  2.  On  the  other  hand  the  phrase 
(x.y)  F  z 

is  a  predicate,  as  is  the  phrase: 

(x.y)  F  (x  F  y) 

For  the  moment  our  language  doesn't  have  to  be  understood  by  computers,  so  there's  no 
need  when  defining  a  function  F  to  say  whether  xFy  or  FCx.y)  is  the  form  we’ll  use. 
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3.4  Specification  by  Predicate 

We  have  hitherto  defined  relations  and  functions  by  giving  extensional  or  comprehensive 
specifications  of  sets  of  pairs.  We  now  introduce  a  more  convenient  style  of  specification, 
namely  "by  predicate”.  For  example,  here  is  a  specification  of  the  relation  "is  the  square 
or 

i 

squares:  N  «-*  TNT 


V  n:N:  i:  I  NT  . 

(n  squares  i)  (i*  =  n) 


and  here  is  a  specification  of  a  fairly  uninteresting  total  function 


boring:  N  — >  N 


v  n:N  .  boring  n  =  nJ  +  31n  2 


The  defining  predicate  is  equivalent  to  the  predicate 
boring  *  (  n:W  .  n*-*n*'*-31n-*'2  > 

If  we  were  being  careful  we  would  check  that  the  polynomial  term  denotes  a  natural 
number  for  all  n:N  for  if  it  did  not,  then  the  defining  predicate  would  not  be  consistent 
with  the  signature;  this  is  because  the  signature  requires  that  the  constant  boring  take  its 
value  from  the  set  of  total  functions  from  K 


Finally  here  is  a  specification  of  the  function  which  maps  a  nonempty  set  of  numbers  to 
0|  its  minimum  element  (P,  means  the  set  of  nonempty  subsets) 


Vi 

> 

ft 


„v 


j? 
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Notice  that  in  this  latter  case  we  give  no  hint  about  how  to  discover  the  number  in 
question,  we  just  give  its  properties.  Such  property-oriented  specifications,  particularly  of 
functions,  may  seem  a  little  strange  to  programmers  who  are  used  to  giving 
"computational  recipes”;  notwithstanding  this  they  are  widely  used  in  mathematics. 

One  slight  abuse  of  language  which  we  permit  is  to  omit  the  topmost  universal 
quantification  when  to  do  so  would  cause  no  confusion.  This  is  usually  the  case  when 
specifying  relations  or  (total)  functions,  for  example 


squares:  N  *-*  TNT 
boring:  N  — *  N 


n  squares  i  *—  i’=n 
boring  n  =  n1  *  31n  ♦  2 
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3.5  \-expressions 

In  some  branches  of  computer  science  it  is  customary  to  denote  functions  by  (so-called) 
lambda-expressions.  The  following  syntactic  equivalence  defines  these  terms: 

\  Signature  I  Predicate  .  Tern  a 

(  Signature  I  Predicate  .  (variables  of  Signature)  >— *  Tern  ) 

For  example: 

X  a,  n:N  I  a>n  .  (m+n,a-n)  a 
(  n,  n:N  |  m>n  .  (n,  n)»-*»(a+n,  a-n)  ) 

which  denotes  a  function  which  maps  pairs  of  numbers  into  pairs  of  numbers. 

Exercise: 

Write  down  a  term  which  denotes  the  range  of  the  function  denoted  by 


X  Signature  1  Predicate  .  Tern 

Notation: 

If  0  is  a  binary  infix  operator  with  signature  _  0  _  :  X  x  Y  — ►  Z,  then 

(_  0  y)  a  X  x:X  .  xOy  and  (xO_)aXy:Y.  xQy 

For  example  consider  _  ♦  N  x  N  — *  N  and  _  -  N  x  N  — ♦  N 

(3  *  _)  is  a  function  which  adds  3  to  its  argument 

(55  -  _)  is  a  function  which  subtracts  its  argument  from  55. 


3.6  On  Unsatisfiable  Specifications 

The  pattern  of  much  of  the  software  architect's  work  is  to  specify  what  a  problem  is, 
using  the  mathematical  notation,  then  go  on  to  discover  whether  or  not  the  specification  is 
satisfiable.  It  is  important  to  realise  that  the  language  of  mathematics  is  sufficiently 
powerful  to  allow  us  to  specify  things  which  may  not  exist.  For  example,  consider 


I 

boring?:  H  — *  N 


Y  n:N  .  boring?  n  *  na  -  31n  ♦  2 


In  this  case  the  polynomial  tern  doesn't  denote  a  natural  number  for  all  values  of  n,  so 
the  specification  is  unsatisfiable.  In  other  words,  whilst  there  is  a  partial  function  on  the 
natural  numbers  with  the  indicated  property,  there  is  na  such  total  function.  Now 
consider: 


1 

pr  ime’’:  N 


v  n:  primes  .  prime’’  >  n 


Unsatisfiable  specifications  aren’t  always  so  immediately  and  demonstrably  unsatisfiable! 
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4:  The  Mathematical  Toolkit 


We’re  now  in  a  position  to  use  the  definitional  notation,  introduced  earlier,  to  introduce 
the  "kit'*  which  well  need  for  subsequent  specifications. 

4.1  Operations  on  Sets 

If  X  is  a  set,  then  we  can  specify  the  difference,  union,  and  intersection  operations,  and  the 
inclusion  relations)  on  subsets  of  X  as  follows: 

CXI 


_  >•  _i 

_  e  (P  X)  *—  (P  X) 


S,  :  S,  •*  Y  x:S,  .  x«S, 
S,  C  S,  »  (S,*S,  A  S,CS,1 


These  operators  have  a  large  number  of  properties,  with  which  every  aspiring 
mathematician  and  computer  scientist  must  become  familiar.  If  you  have  any  doubts  about 
your  understanding  of  them  then  do  the  exercises  in  f  UpschutzJ . 


4.2  Functions  and  Relations  as  ’’Data’* 

Functions  and  relations  whose  domains  or  ranges  are  sets  of  functions  or  relations  are 
called  "higher  order" .  It  is  important  to  understand  that  higher  order  functions  and 
relations  are  as  easy  to  define  as  the  "simple*  functions  and  relations  we  have  met  up  to 
now. 

First  we  take  a  practical  example  let  us  suppose  that  we  wish  to  model  a  database  which 
records  the  owners  of  cars.  If  we  make  the  simplifying  assumption  that  every  registration 
number  has  an  owner  (perhaps  the  "ministry  of  transport")  then  the  state  of  this  database 
at  any  stage  in  its  evolution  can  be  modelled  by  a  total  function  of  type  DB  defined  by 

DB  «  REG  -*  OWNER 

A  family  of  transactions,  each  of  which  records  the  fact  that  a  person  a  has  bought  a  car 
whose  registration  is  r  can  be  modelled  by  the  function- 


buys:  (OVNERxREG)  -*  ( DB— *DB ) 


This  is  a  function  of  two  arguments,  whose  result  is  itself  a  function.  For  each  owner  a 
and  registration  r  there  is  a  function 

a  buva  r 

which  maps  our  model  of  the  state  of  the  database  before  the  transaction  into  our  model 
of  its  state  after  the  transactioa 

Since  the  model  of  the  database  is  itself  a  function,  we  evidently  have  defined  a  function 
whose  result  is  a  function  from  functions  to  functions.  This  may  be  a  bit  mind-blowing 
for  people  who  are  used  to  programming  in  languages  where  functions  aren't  "first-class’* 
objects:  remembering  that  we  are  writing  in  a  descriptive  language  rather  than  a 
programming  language  may  help  to  calm  you  down. 

Notice  that  we  used  union  and  set  difference  to  describe  the  relationships  between  the 
functions  modelling  the  database  before  and  after  the  transaction.  This  is  perfectly 
legitimate:  the  sets  are  (in  this  case)  sets  of  pairs.  This  is  where  the  mathematical  idea  of  a 
function  (relation)  as  a  set  of  pairs  begins  to  pay  off;  we  can  operate  on  functions  and 
relations  using  the  same  operators  as  we  use  to  operate  on  sets.  In  the  next  section  we  use 
this  freedom  in  order  to  specify  some  very  powerful  operators  indeed. 


4.3  Operations  on  Relations  and  Functions 

An  operator  which  may  already  be  familiar  is  (forward)  composition  of  relations,  defined 
by 


nada by  = 

{  a420gbh»— 1 ►Renault,  rwr360w*— *Horria, 

pva495>-*tlorris,  is400p<— 'Dataun,  al90>— *Bentley  > 

Then  the  relation  ownaacaraadaby,  defined  by 

ownaacaraadaby  =  owns  t  nadeby 

is  (in  extenso) 

(  BS>— 'Morris,  TH^-'Ranault,  IS^-*Datsun  > 

Notice  that  it  also  happens  to  be  a  functioa 
Some  authors  also  use  the  sign  •  defined  by: 


:  (Y«-»Z)  x  ( X*— >Y)  — >  (X*-*Z) 


R,  •  R,  *  R,  I  R, 
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4.4  A  Simple  Example:  Family  Life 

Suppose  we  are  designing  a  database  in  which  to  keep  information  about  families.  Let  P 
denote  the  set  of  all  persons;  each  person  has  but  a  single  biological  mother  and  a  single 
biological  father  and  we  capture  this  fact  by  introducing  two  partial  functions 

aa.  pa:  P  ■**  P 

The  functions  are  partial  because  we  cannot  hope  to  record  this  information  about 
everybody  who  has  ever  lived.  We  do  insist,  though  that  ever  body  who  has  a  mother  has  a 
father  and  vice  versa,  (thereby  ruling  out  immaculate  conception).  We  also  know  that 
nobody  can  be  both  a  father  and  a  mother,  and  record  these  real-world  constraints  by 
adding  the  predicates 

do*  aa  =  do a  pa 
ran  aa  ft  ran  pa  =  <) 

to  our  specification.  For  the  moment  we  shall  ignore  several  other  real-world  constraints. 
We  can  now  define  several  other  family  relationships  using  composition  and  union.  For 
example: 


In  order  to  define  brother  and  sister  we  need  a  few  more  tools. 
The  inverse  function 


I 

i r 
j- 


V 


I 

inv:  (X«-*Y)  -*  ( Y*-*X) 

(y.x)«(inv  R)  (x.y)fiR 
maps  a  binary  relation  into  its  inverse. 

Notation:  if  R  is  a  relation  then 
RM  a  (inv  R) 

For  example: 

made  by  =  made'* 

Note  that  the  inverse  of  a  function  is  not  necessarily  a  functioa  For  example,  consider  the 
function: 

♦  :  N  x  N  —  N 
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Its  inverse  is  a  relation  which  holds  between  every  number  n  and  any  pair  of  numbers 
whose  sum  is  n. 

Exercise: 

Write  a  camprehensn/e  specification  of  the  inverse  of  +. 

The  identity  relation  on  subsets  of  a  set  is  defined  by 


Id:  (P  X)  -*•  (X~X) 


Id  S  =  (  x:S  .  x*-*x  > 


Exercise: 

Summarise  in  prose  the  "effect”  on  a  relation  of  composing  it  on  the  left/right  with  an 
identity  on  a  proper  subset  of  its  domain/range?  Suppose  that  R  is  a  relation,  S  is  a 
subset  of  its  domain  and  T  is  a  subset  of  its  range.  Write  down  terms  which  denote  the 
set  of  pairs  which  comprise  the  relations. 

R»(  Id  T) 

( Id  S) ;R 


Resuming,  for  the  moment,  our  "family  life”  example,  let's  now  suppose  that  we  keep  a 
record  of  who  is  male  and  who  is  female;  nobody  is  both: 


■  n  f  =  { } 
a  U  f  =  P 


The  real-world  constraint  which  requires  mothers  to  be  female  and  fathers  to  be  male  is 
recorded  by- 

ran  pa  s  a 

ran  aa  s  f 

The  relations  sister  and  brother  are  now  (almost)  respectively  definable  by 

parent  >  parent'*  >  (Id  f) 

parent  ;  parent'*  I  (Id  a) 

All  that  is  left  is  to  prevent  males  from  being  their  own  brothers  and  females  from  being 
their  own  sisters: 

sister  =  (parent  I  parent'*  I  (Id  f))  -  (Id  £) 
brother  =  (parent  f  parent'*  I  ( Id  a) )  -  (Id  m) 


Notice  that  we  used  right-composition  with  an  identity  relation  to  restrict  the  size  of  a 
relation.  The  following  operators  restrict  relations  by  specifying  a  restriction  on  their 
domain  and  range  respectively: 


r 

:  (X«-*Y) 

X 

(P 

X) 

- ! 

—  ( X<—»Y) 

- 

\ 

:  (X«-*Y) 

X 

(P 

X) 

-*  (X<->Y) 

R 

r 

S  =  (id  S) 

1 

R 

R 

\ 

S  =  R  r  (X- 

-S) 

4 

(X<-*Y)  x  (p 

Y) 

1 

->  ( X*-*Y) 

_  / 

-  : 

(X<-»Y)  x  (p 

Y) 

— *  ( X«-+Y) 

R  4 

T 

a  R  1  (id  T) 

R  / 

T 

a  R  4  (Y-T) 

The  domain  restriction  operator  may  be  used  with  its  operands  reversed,  as  if  defined  by: 


! 

r  _  :  (P  X)  x  (X«->Y)  -»  (X<-*Y> 


S  r  R  =  (id  S) |R 


For  example. 


(X  x:N  .  Xs)  r  <  2.3  >  a  <  2*— *4,  3«-»9  > 
(X  x:N  .  x3)  4  <  2.3  >  a  {  > 

(X  x:N  .  x3)  4  1.  .8  a  {  2*-*4  ) 

{  2.  3  >  t  (X  x:N  .  x3)  -  (  2»-+4t  3*-+9  > 


4.*>  The  Registration  Database  Revisited 

Consider,  for  a  moment,  the  daubase  example:  in  our  original  definition  of  buys  we  had 
to  write  a  rather  unweildy  term  to  denote  the  database  after  the  transaction.  The  operators 
we  have  just  introduced  allow  us  to  make  this  a  bit  less  cumbersome;  it  is  easy  to  show 
that 


db  \  (r)  U  {  r*— +a  >  =  (a  buys  c)  db 

In  fact  the  idea  of  a  relation  being  like  another  "except  occurs  so  frequently  in 
specification  that  we  introduce  another  operator  —  the  relational  override  operator: 


- , 

_  •  _  :  (X<-»Y)  X  (X<-*Y)  — *  ( X«-*Y) 


R,  •  R,  =  :a,  \  (doa  R,)  )  U  R, 


For  example,  the  function: 


db  •  (  r*—»a  > 


"behaves’*  like  db  except  that  it  maps  r  to  a.  A  slightly  more  interesting  example  is  the 
following  characterisation  of  a  database  transaction  which  allows  "simultaneous” 
registration  of  a  number  of  vehicles  to  a  single  owner  (perhaps  a  car  wholesaler): 


- 1 

bulkbuys:  OWNER* (F  REG)  —  ( DB— *DB ) 


(a  bulkbuva  S)  db  =  db  •  (  r:S  .  r1— *a  ) 


4.6  Generalised  Application:  Image 

The  image  of  a  set  S  through  a  relation  R  (sometimes  called  the  R~image  of  S)  is  the  set 
of  elements  of  R’s  "destination”  to  which  R  maps  elements  of  S.  The  function 


la:  (X  <-  Y)  — *  (<P  X)  -*•  (P  Y) ) 


la  R  S  =  {  y:Y  |  (3  x:S  .  xRy)  > 


maps  a  relation  R  into  a  function  which  maps  a  set  S  of  elements  into  its  image  through 

R. 

For  example,  consider  the  relation  owna  of  section  1  here  are  some  examples  of  images 
through  it 

la  own*  (BS)  »  <rwr360w,  pv*495) 

la  own*  (BS.  RB)  *  (rwr360w,  pva495) 

la  owna  <TH,  BS)  =  <rwr380w.  a420gbh.  pv*495> 

Notation:  if  R:X«-»Y  is  a  relation  and  S  a  subset  of  Y,  and  y  an  element  of  Y  then 

R  (  S  1  a  la  R  S 

R  [  y  ]  a  la  R  (y) 

For  example 

owna  (  (IS)  ]  »  <ia400p> 

owna  (  IS  1  =  (is400p> 

owna  (  <RB,  IS,  TH>  ]  *  (ia400p,  a420gbh) 

owna  [  ( )  1  a  ( ) 


4.7  Properties: 

If  R.  Rl,  R,;X«->Y  are  relations,  and  if  S,  S,  and  S,  are  subsets  of  X,  and  if  T  is  a  subset 
of  Y,  then  the  following  predicates  (amongst  others)  always  hold: 


(  R-'  )•'  =  R 
dom  R'1  =  ran  R 
ran  R'1  =  doa  R 

(R,  'J  R,)-’  =  R,-'  u  R,'1 
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!R,  U  R,)(  S  )  =  R,t  S  Ju  R,{  S  } 

at  s,  u  s,  )  =  s(  s,  ]  u  r(  s,  ) 


dom(  R,  )  R,  )  =■  R,'1  (  don  R,  ] 
ran(  R,  »  Ra  )  =  R,{  ran  R,  ] 

doa(  RrS  )  =  SnCdoa  R) 
ran(  R4T  )  *  TA(ran  R) 

Exercises: 

(1)  Prove  the  properties  outlined  above. 

(2)  We  have  outlined  some  properties  of  union  with  respect  to  the  image  and  inverse 
operators;  what  are  the  properties  of  intersection  with  respect  to  these  operators? 

(3)  Siblings  are  people  who  share  the  same  parents.  Half-siblings  share  the  same  father  or 
the  same  mother  but  not  both.  Specify  the  relations  sibling,  half -sibling,,  half-sister,  cousin, 
great-aunt.  What  is  interesting  about  the  relations  cousin  and  sibling?  Can  you  specify  the 
relation  "childless  aunt"? 


4.8  Finite  Sequences 

Finite  sequences  ire  important  because  they  allow  us  to  capture  the  essence  of  entities  as 
diverse  as  lists,  files,  arrays,  memories,  and  histories.  Although  it  is  possible  to  give  an 
abstract  axiomatic  characterisation  of  them,  we  have  chosen  to  formalise  them  as  partial 
functions  from  the  natural  numbers.  As  we  shall  see  below,  this  augments  the  applicability 
of  the  existing  toolkit. 

We  first  define  the  finite  partial  functions  —  they  are  the  partial  functions  whose 
domains  are  finite. 

C X.  YI 

X  -**  Y  a  {  f:  X-»Y  I  doa  £  «  F  X  > 

Given  a  set  X,  the  finite  sequences  of  X  are  the  finite  partial  functions  from  N  to  X 
whose  domains  are  of  the  form  Ln  (for  some  n:N).  More  formally 

— aeqt  Xl - , 

(  f!  MX  I  doi£  »  1..M  ) 


For  example: 

(  2 >—►6,  3>-*77  >  €  aaqtNl 

{  l*-*Ford  i  «  aaq(  MAKER  1 

(  1  ♦  <  > .  2*— ►primaa  )  €  saqCP  N3 

In  general  the  following  syntactic  sugar  is  used  for  extensional  specifications  of  sequences: 

<>  a  {) 

<at>  a  {  l^a,  > 

<a,  ...  a*>  a  {  ...  n>~*a,  ) 


4.8.1  Basic  Sequence-Building  Operators 

One  way  of  building  a  new  sequence  is  to  "push  a  new  element  onto  the  front  of"  an 
existing  sequence,  thus 


- 1 

con8:  (X*aaq.(Xl)  — *  seqCXl 


v  x:X;  a:aaq(Xl  .  x  cona  a  =  {  !•— *x  >  U  predia 


defines  an  operator  which  "pushes’*  an  element  x  onto  the  front  of  a  sequence  a.  It  is 
called  cona  because  it  constructs  a  new  sequence  (it  also  captures  at  least  some  of  the 
properties  of  Lisp’s  cons).  We  usually  abbreviate  this  operator  to  the  infix  sign  *  —  thus 
if  x  is  an  element  of  X  and  s  is  a  sequence  of  Xs 

x  "  a  a  x  cona  a 

We  are  obliged  to  show  that  our  definition  of  cons  is  consistent  with  its  signature,  /e  that 
for  a  sequence  a  and  an  element  x,  the  term  which  defines  x  cons  a  really  denotes  a 
function  with  all  the  characteristic  properties  of  a  sequence. 

If  we  recall  that  the  function  pred  is  the  inverse  of  the  function  sue  on  the  natural 
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numbers,  >e  that: 


pred  *  (  C>— *  1 ,  l*- 1 *2,  ...  >'* 

=  {  ....  2*-»l.  !•— *0  > 

Then,  by  virtue  of  the  deTinition  of  composition  (see  earlier). 

doa(  predja  )  *  pred‘'(doa  a) 
s  suc( 1 . . *s] 

=  2. .#8+1 

and  so 

doa(  (  1>— • >x  )  U  (predja)  )  =  l..#a+l 
#(  (  1>— >x  )  u  (predja)  )  =  l+#a 

which  is  exactly  what  the  sequence  axioms  require 

A  more  concrete  example  is 

44"  <33  22>  =  (  l>-*44  )  U  {  2»-»33,  3>-+22  > 

■  <44  33  22> 

In  fact  the  sign  *  is  overloaded  (just  as  the  sign  -  means  both  arithmetic  subtraction  and 
set  difference).  It  also  denotes  an  operator  (pronounced  "snoc"  if  you  like)  which  pushes 
an  element  onto  the  end  of  a  sequence,  namely: 


anoc:  (aeq(XlxX)  — *  X 

V  x: X;  a: seqlXl  .  a  anoc  x  ■  a  U  {  auc  #a  •-»  x  ) 
If  x  is  an  element  of  X  and  a  is  a  sequence  of  Xs  then 


a  *  x  a  a  anoc  x 

When  the  sign  *  is  used,  it  should  always  be  clear  from  context  (or  to  be  more  precise, 
from  the  types  of  its  operands)  whether  the  "cons’*  or  the  "snoc"  operator  is  meant.  In 
cases  where  this  is  not  so,  we  will  use  8noc  and  cona  themselves;  sometimes  in  proofs  we 
add  a  little  arrowhead  to  the  *  for  readability  —  thus 

**  a  cona 

**  a  anoc 

4.8.2  Operators  on  Sequences 

Many  sequence  operators  have  domains  which  are  the  nonempty  sequences,  defined  by: 

1X1 

aeql  a  seqlXl  -  {<>) 

For  example  hd  and  ci  which  behave  rather  like  the  Lisp  operators  car  and  cdr. 


£ 


g 


i 


v  „ 


9 


<v. 


hd.  last:  ssql(X)  - 
tl,  front:  seql(X) 


seq(X) 


x:X:  3:soq[X]  . 
hd(  X  **  S  )  ax 

last(  s  x  )  »x 
tl(  X  *’  3  )  as 
front(  s  x  )  =s 


Exercise: 

We  have  specified  these  operators  nonconstructive  Jy  —  that  is  by  giving  predicates  which 
relate  them  to  cons  and  snoc  rather  than  by  giving  terms  which  denote  the  set  of  pairs  to 
which  they  correspond. 

Prove  that  the  following  constructive  definitions  satisfy  the  specifications  for  hd,  front, 
tl,  and  last. 


A 

>. 

'£* 


i 

£ 

1 


'i 


9 

i 

l 


I 


hd  a  X  s:a«q(Xl  I  s *<>  .  (si) 
front  a  X  s:saq(X)  I  s*<>  .  sf(l..(prsd  is)) 

tl  a  X  s: ssqCXl  I  s*<>  .  sue  is  \  (0) 
last  a  X  a:ssq(Xl  |  s*<>  .  s(is) 

We  will  use  the  same  style  of  specification  for  the  operator  which  appends  two  sequences, 
namely 


_  *  _  :  ssqCXJxssqCXl  ~ *  ssq(X3 


1 


V  s: ssqCXl  . 

<>  »  S  a  s 

V  3,,  s,:  ssqCXl;  x:X  . 

(X*S,)»8,  a  x'(s,*Sa) 


....  app.l 


....  app.Z 


What  we  have  done  is  to  specify  the  result  of  appending  any  sequence  to  the  empty 
sequence;  and  then  specify  the  result  of  appending  a  sequence  s,  to  a  nonempty  sequence  in 
terms  of  the  result  of  appending  s,  to  the  tail  of  the  nonempty  sequence;  since  all 
sequences  are  either  empty  or  nonempty  we  have  covered  all  possible  cases,  and  you  might 
think  that  for  this  very  reason  that  a  function  which  satisfies  the  above  specification  must 
therefore  exist.  This  is  indeed  the  case,  but  it  neeed  not  be  so  in  general.  Later  in  the 
course  we  shall  see  that  a  certain  class  of  "recursive"  specification  is  always  satisfiable,  and 
that  this  specification  falls  into  that  class.  For  the  moment,  though,  we  will  demonstrate  a 
constructive  solution  to  the  equations  above,  namely: 


_  »  _  =  X  s,,3t:seq(X]  . 

3,  U  (shift  t»s,)  is. 
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"A 

V. 

v 


where 

shift:  N  — ♦  N  — ♦  IN 
shift  a  n  =  n-a 


* 

» k  • 


Exercise: 

Think  about  the  strategy  you  would  use  to  prove  that  this  definition  satisfies  the 
specification. 

The  last  standard  operator  on  sequences  is  the  one  which  reverses  them,  specified  by: 


rev: 

seqlXl  — * 

""1 

saqCXl 

rev 

<>  S  <> 

....  rev .  1 

rev 

( x  cons  a ) 

=  (rev  a)  snoc  x 

- rev  .Z 

Exercises: 

(1)  give  a  constructive  definition  which  satisfies  this  specification. 

(2)  try  to  prove  that  the  following  theorems  hold  given  that  x  is  an  element  of  X  and  s, 
s,  .  $,  are  all  sequences  of  Xs  _ 


3,  * 

(a,  *  a3) 

=  (a,  *  s,)  *  3] 

.... 

(Til 

a  * 

<X>  =  3  - 

x 

.... 

(TZ) 

r«v( 

8,  *  S,  ) 

a  (r«V  3,1  *  (r»V  B,> 

•  •  •  • 

(T3) 

■r.  (revjrev)  a  =  a  ....  (T-f  > 

y. 

<X>  a  X  *  <>  ....  (TSl 

$ 

y.  4.8 J  Reasoning  about  Sequences 

£■’  The  well-known  principle  of  mathematical  induction  allows  us  to  begin  to  reason  about 

sequences.  Summarised  in  set-theoretical  form  it  states  that  if  a  certain  set  of  natural 
—  numbers  is  known  to  contain  n+1  whenever  it  contains  n,  and  if  it  is  also  known  to 

A*  contain  zero,  then  in  fact  it  contains  all  the  natural  numbers.  Formally,  we  have 


s 


* 


v 

:< 


i 


►-  V  S:P  N  . 

( 

0«S  A 

V  n:S  .  n+l«S 
)  —  S=N 

It  is  clear  that  this  principle  could  be  extended  to  the  sequences  —  for  we  could  prove 
things  by  induction  over  their  lengths.  The  following  theorem  is  easily  proven  from  the 
principle  of  mathematical  induction: 

-  V  SS:P  (aeqfXJ)  . 
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5 


<>  «  SS  A 

V  s : SS i  X:X  .  X*3  «  SS 
)  —  SS=seq[ Xl 

This  result  is  called  the  principle  of  finite  sequence  induction.  It  is  a  special  case  of  a 
much  more  general  result  which  we  shall  examine  later  in  the  course,  namely  the 

principle  of  structural  induction. 

In  order  to  show  how  to  use  this  principle,  we  shall  prove  that  the  set  SS  of  sequences  s 
which  satisfy 

(revjrev)  339 

contains  ail  the  sequences.  More  formally,  if 

SS  a  {  s:s«qIXl  !  (revjrev)  333) 

then 

SS  *  saqlXl 

Our  proof  is  structured  along  the  lines  of  the  induction  principle  —  we  will  first  prove 
what  is  called  the  Base  Case: 


(1) 

(revjrev) 

<> 

3  rev(rev  <>) 

. .  .  composition  def  inition 

(2) 

( revjrev) 

<> 

3  (rev  <>) 

1.  rev.l 

(3) 

(revjrev) 

<> 

a  <> 

•  •  •  4m  0  FQbS 

(4) 

<>  e  SS 

•  • 

...  3.  SS  def  inition 

Next  we  perform  what  is  known  as  the  Induction  Step.  To  do  so  we  must  show, 
given  a  sequence  s  in  SS  and  an  element  x  in  X,  that  x  *  ■  is  in  SS.  Suppose,  then  that  s 
is  a  sequence  in  SS;  this  supposition  is  called  the  induction  hypothesis  and  from  it  we 
proceed  formally  as  follows 


(5) 

a«SS 

•  •  . 

(Q) 

(revirev)  339 

.  .  . 

(7) 

rev  <x>  3  <x> 

(8) 

rev(  rev(  x*  a  )  )  3  rev(  (rev  9) 

(9) 

!  3  rev(  (rev  a)  »  <x>  ) 

(10) 

!  3  (rev  <x>)  *  (rev  (rev 

9)) 

(11) 

!  3  <x>  *  3 

(12) 

!  3  (X  *  <>)  »  9 

(13) 

!  3  x  *  (0*3) 

(14) 

!  3  X  •  8 

(15) 

v 

x:  X;  3 :  SS  .  s«SS  -*  x*s  « 

SS 

Induction  Hypothesis 
S.  SS  definition 
Lemma  (  see  later  > 

x  )  ...  rev .Z 

.  S.TC 

.  3.  73 

.  10.  Z .  S.  composition  def 

.  11.  TS 

.  AT.  app.Z 

.  13.  app . 1 

.  Generalisation 


This  completes  the  second  part  of  the  proof;  we  can  now  apply  the  sequence  induction 
principle  and  conclude  that  SS  contains  all  the  sequences. 

The  !  on  the  left  hand  side  of  the  equalities  on  lines  9J4  stands  in  each  case  for  the  term 
on  the  right  hand  side  of  the  previous  line;  it  just  saves  typing. 
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Each  line  in  our  proof  consists  of  a  numbered  fact  or  hypothesis,  supported  by  some 
evidence.  In  each  case  the  evidence  consists  of  a  reference  to  a  previously-numbered  fact, 
and/or  a  predicate  from  a  definition,  and/or  a  theorem  (or  Lemma  —  which  is  just  a 
“local"  theorem)  which  is  proven  elsewhere. 

The  local  "lemma"  was 

>-  V  X-.  X  .  rav<x>  =  <x> 

Proof  (left  as  an  exercise). 

4.8.4  Useful  Properties 

If  s  is  a  sequence  of  elements  of  X  and  if  £  is  a  function  whose  domain  includes  the  range 
of  a,  then  the  composition  of  a  and  £  is  also  a  sequence.  More  formally: 

V  a:  seqCXl ;  f:X-«Y  . 

(ran  a)s(dom  £1  -•  ts»f)«o«q(Y] 

If  a  sequence  s,  is  a  prefix  of  a  sequence  s^  then  the  set  of  pairs  which  constitute  s,  is  a 
subset  of  the  set  of  pairs  which  constitute  s,  More  formally: 

>-  V  3l,32:aaq(X]  . 

3a:aaqCXl  . 

al»B=a2  •-*  alsa2 

For  this  reason  we  usually  use  the  "subset"  relation  between  sequences  to  mean  "is  a 
prefix  of".  This  is  an  example  of  an  idiom. 

If  s  is  a  sequence,  then  the  relation  "are  adjacent  elements  in  s"  is  captured  by  a  relatively 
simple  formula,  namely: 

a*  jaucla 

Exercises: 

(1)  prove  the  following  theorem 

I-  V  a:aaq(Xl:  xi,x2:X  . 

(xl,  x2 )  «  s'lauccja 

3i:(l..#a-l)  .  a  i  =  xl  *  a(i+l)  =  x2 

(2)  use  the  above  fact  to  give  a  simple  specification  of  the  set  of  sequences  of  X  which  are 
"ordered  with  respect  to"  a  homogeneous  relation  "<*  on  X. 
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5:  Disjoint  Unions,  Recursive  Types,  Enumerated  Types 
5.1:  Introduction 

In  previous  sections  we  introduced  ways  of  making  neu  types  of  set  from  existing  sets,  but 
did  not  say  anything  about  the  "primitive’*  sets  of  the  language.  Indeed  in  order  to  avoid 
discourse  about  primitive  sets  we  "parachuted”  the  natural  numbers  (N)  into  our  discussion 
without  really  defining  them.  In  this  section  we  introduce  the  only  notation  by  which 
new  primitive  types  of  set  are  defined.  We  also  show  how  the  notation  may  be  used  to 
define  abstract  forms  of  the  tree-like  structures  which  are  common  objects  of  discourse  in 
Computing  Science.  This  notation  is  currently  used  by  practitioners  of  the  "Z"  style  of 
specification;  there  is  no  corresponding  "standard"  notation 


5.2:  Strong  Typing 

Although  we  have  not  yet  introduced  any  of  the  consequences  which  flow  from  it,  the 
language  we  have  introduced  so  far  is  strongly  typed.  What  this  means  is  that  certain 
terms  and  predicates  are  defined  by  us  to  be  well-typed,  whereas  others  are  ill-typed;  in 
general  we  only  provide  means  of  reasoning  about  well-typed  terms  and  predicates. 

The  role  played  by  type-analysis  in  mathematics  is  analogous  to  that  played  by  dimensional 
analysis  in  physics  and  mechanics;  it  is  a  safeguard  against  writing  utterly  nonsensical 
mathematical  terms  and  predicates,  but  is  no  guarantee  that  the  mathematical  model  is  true 
to  reality  or  even  consistent. 

A  complete  explanation  of  the  type  rules  is  beyond  the  scope  of  these  notes,  but  we  can 
illustrate  their  spirit  by  briefly  considering  the  union  operator,  which  has  generic  type 
specified  by  the  signature: 

CXI 


U:  (P  X)  x  (P  X)  -*  (P  X) 

This  means  that  every  instance  of  the  union  operator  must  have  operands  which  both  have 
type  P  X  —  far  same  primitive  type  of  set  X  —  and  that  its  result  is  also  of  type  P  X. 

Now  suppose  that  Y  and  Z  are  distinct  primitive  types  and  that  y  is  of  type  Y  and  s  and 
t  are  of  type  P  Z;  in  other  words: 

y:  Y 

a:  P  Z 

t:  P  Z 

Then  the  term 

m  u  c 

is  well-typed  because  the  generic  parameter  X  in  the  type-specification  of  the  union 
operator  can  be  instantiated  with  the  primitive  type  Z.  On  the  other  hand,  none  of  the 
terms 


y  U  y 
y  u  s 
a  u  z 

a  u  Y 
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are  well-typed,  because  in  none  of  these  cases  can  we  find  a  suitable  instantiation  of  the 
type  variable  X. 

In  the  next  section  we  introduce  a  new  category  of  type-constructor  which  allows  us  both 
to  overcome  certain  problems  introduced  by  strong-typing,  and  to  describe  certain  kinds  of 
“recursively-specified”  sets  (sometimes  called  trees). 


5.3:  Disjoint  Union 

Suppose  for  a  moment  that  we  want  to  specify  a  function,  find,  which  searches  a  list  of 

words  for  a  particular  word,  say  foo,  and  either  returns  its  index  (if  it  appears  once)  or 

an  error  code  indicating  whether  it  appears  more  than  or  less  than  once.  Let  us  suppose 
that  the  set  of  error  codes,  call  it  E,  is  primitive  (generic),  and  that  the  set  of  words,  call 
it  V.  is  also  primitive. 

How  do  we  write  a  signature  for  the  function  we  have  in  mind?  Clearly 
find:  aeq(V]  — *  (E  u  H) 

will  not  do,  for  there  is  no  primitive  type  of  set  of  which  both  N  and  E  are  subsets  and 

so  the  u  term  on  the  right  of  the  function  arrow  is  ill-typed.  What  we  need  on  the 

right  of  the  arrow  is  a  type  of  set  which  contains  “as  many”  elements  as  there  in  N  and  E 
combined,  but  in  which  there  is  no  confusion  between  numberish  and  errorish  things. 

One  such  set  is 

N  *  E  x  <0. 1) 

where  the  third  component  of  each 
(n.  •.  which) 

triple  indicates  whether  the  n  or  the  •  part  is  the  real  information  contained  in  the  triple. 
This  is  unsatisfactory,  firstly  because  it  is  only  one  of  a  number  of  possible  “codings”,  and 
secondly,  because  it  is  “overkill”  in  the  sense  that  each  number  has  several  possible 
representations  in  the  coding,  namely 

(n,  trrnoin,  0)  (n,  erraany,  0)  (n,  errovarflow,  0)  ... 

and  each  error  has  an  infinity  of  representations  in  the  coding,  namely: 

(0.  err none,  1)  (1,  err none.  1)  ...  t 567880,  errnone,  1) 

(0.  erraany,  1)  (1,  erraany,  1!  ...  ... 

(0,  erroverflow,  1)  ...  ...  ... 

Mathematicians  abhor  clutter,  so  it  is  perhaps  not  surprising  that  our  notation  allows  us  to 
describe  precisely  the  set  which  is  needed,  namely  one  which  has  exactly  one  element  for 
each  element  of  E  and  exactly  one  element  for  each  element  of  N.  The  term 


error<<E>>  1  result<<N>> 


denotes  such  a  set.  The  identifiers  result  and  error  are  chosen  for  their  mnemonic  value, 
not  for  any  technical  reason. 

If  we  call  this  set  S  (which  we  can  do  in  the  usual  way  by  putting  the  name  S  on  a  box 
around  it). 

S  - , 

error<<£»  I  result<<N>> 


then  the  following  injective  functions  are  defined  "automatically”. 


error:  E  S 

result:  N  >-»  S 

- 1 

ran  error  u  ran 

ran  error  0  ran 

result  3  s 

result  =  ( ) 

The  axioms  for  these  functions  indicate  precisely  that  there’s  neither  junk  (the  union  of  the 
ranges  of  the  functions  is  exactly  S)  nor  confusion  (the  ranges  are  disjoint). 

Moreover,  because  the  functions  are  injective{.?o*  Appendix  f/J,  their  inverses  are  also 
functions,  so  that  given  an  element  s:S  —  then  if  it  "stands  for”  an  error  code,  /e  if 

s€(ran  error) 

then  the  one  in  question  is 

error'*  ■ 

Likewise  if  it  stands  for  a  number, 
s€(ran  result) 
then  the  one  in  question  is 
result'*  s 

We  are  now  in  a  position  (for  better  or  for  worse)  to  specify  the  function  we  first 
thought  ovf.  First  we  introduce  some  constants  to  denote  the  word  being  sought  and  the 
error  codes: 


£oo:  V 
none :  E 
many:  E 
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Hiving  done  so  we  can  specify: 


find:  seqCW] 


V9: seqt  V] 
*index=0 
#index>l 
»indax=l 
where 


find  s  s  error  none 
find  s  =  error  many 
find  9  e  result!  index 


index  -  s"‘(  (  foo)  } 


J 


5.4:  General  Characterisation  of  Disjoint  Union 

In  general  if  SI  .  Sn  are  terms  which  denote  sets,  and  if  idl  -  idn  are  identifiers,  then 
the  term: 


id,«S,»  I  . . .  I  id,«S,» 

denotes  a  new  set.  Such  set-denoting  terms  hardly  ever  appear  without  being  named,  which 
is  done  in  the  usual  manner,  for  example: 


id1«S,»  I  ...  I  id,«S,» 


In  this  case  the  following  constants  are  defined  and  remain  in  scope  for  as  long  as  the 
name  0. 


id,  :  S,  >-*  D 
id,  :  S,  >-*  D 


id,  :  S,  >-»  D 


<  ran  id,  ...  ran  id,  >  partitions!  D 


and  —  as  you  might  have  expected  —  the  ranges  of  these  injective  functions  partition 
f  see  Appendix  /  /  the  new  set. 


5.5:  Reasoning  Methods 

The  principal  method  of  reasoning  about  disjoint  unions  is  based  on  the  following 
(meta)-theorem. 

P:  P  D 
( 

VS:S,  .  (id,  3)  €  P  A 


Vs: S,  .  (id,  s)  €  p 
)  -»  P=D 

Which  expressed  informally  reads:  if  a  certain  property  (the  characteristic  predicate  of  P) 
holds  for  all  ways  of  constructing  an  element  of  D  then  it  holds  for  all  elements  of  0. 

Special  Case:  Enumerated  Types 

The  term 

id,  I  ...  I  id, 

denotes  a  "new”  set  If  this  set  is  named,  (E  say)  then  the  following  constants  are  defined 
and  remain  in  scope  for  as  long  as  the  name  E. 


Moreover  they  all  denote  different  elements  of  E. 

Technical  Note:  In  fact  this  is  the  only  correct  nay  to 
introduce  a  m  nan"  type  consisting  of  an  enumeration  of 
elements.  The  def mition 

E  a  (  £oo,  baz,  blah  > 

(  uhtch  /s  occasionally  used  mth  the  / mention  of  defining  an 
enumerated  type  >  means  nothing  at  all  m  our  notation  except 
m  the  scope  of  foo  baz  and  blah,  and  even  then  it  may  not  be 
uel  1— typed  ! 
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5.6:  Hybrid  Case 

Terms  of  the  form 


id,  I  id,<<SJ>>  I  ...idj«Sj>>  I  id. 

(in  which  some  of  the  identifiers  stand  alone)  are  perfectly  valid  When  such  a  term  is 
named  (H  say)  the  following  constants  are  defined: 


The  pattern  should  be  obvious.  The  stand-alone  identifiers  correspond  to  constant  elements 
of  the  new  type,  the  remaining  elements  correspond  to  injective  functions  into  the  new 
type.  The  elements  of  the  type  are  partitioned  appropriately. 


5.7:  Recursive  Types 

Trees  occur  sufficiently  frequently  in  the  world  of  specification  that  it  is  useful  to  have  a 
small  library  of  conceptual  tools  with  which  to  manipulate  and  reason  about  them.  It  is 
rather  convenient  to  be  able  to  specify  trees  '"recursively”,  but  we  have  to  take  some  care 
when  doing  so. 

Let  us  consider,  for  the  moment,  the  problem  of  specifying  what  is  a  Lisp(lrit)-Iist 
Informally. 

A  list  is  either  an  atom  or  a  pair  of  lists 

Clearly  it  doesn’t  matter  what  the  internal  structure  of  the  set  of  atoms  is,  we  will  denote 
this  set  by  A  and  try  to  construct  a  (strictly)  set-theoretic  specification  of  the  lists: 

L  =  A  U  (L  *  L) 

What  we  are  trying  to  convey  here  is  that  the  set  of  lists  contains  all  the  atoms  and  is 
closed  under  the  pairing  operation.  Unfortunately  this  "specification”  of  the  set  of  lists 
has  no  solution  because  the  strong  typing  prevents  it  ( Scottophiles  please  note:  ue 
mean  mno  solution  m  our  set  theory” the  sign  -  means  something  different  in 
Scatter  y./ 

We  can  be  satisfied  with  a  set  which  is  rich  enough  to  contain  one  representative  for  every 
A  and  one  for  every  pair  of  L.  It  turns  out  there  is  a  set  which  has  just  the  properties  we 
want;  it  is  defined  in  our  notation  by: 


«%  , 

£ 

I  *  ' 


;v 

k 


9 


,V 

V. 


£ 


atoa<<A>>  |  cons<<LxL>> 


The  theory  (due  to  Tarski)  behind  such  recursive  specifications  is  simple  and  elegant:  its 
details  need  not  concern  us  here,  but  as  might  be  expected  we  have  recourse  to  the 
techniques  we  used  in  defining  disjoint  unions.  In  essence  the  equation  implicit  in  the  above 
definition  has  a  solution  because  given  a  set,  C  say,  which  is  big  enough  to  "carry'*  the 
lists,  and  given  injections 


atoa: 

A  >-*  C 

- 1 

cons: 

Cxc  >-»  C 

(ran 

con*)  n  (ran  atoa)  *  (} 

whose  ranges  are  disjoint,  it  is  possible  to  discover  a  subset  of  C 

L:  P  C  ' 

which  has  the  properties 

atoa(  A  )  s  L 
cons(  L  x  L  1  S  L 

In  other  words  it  contains  an  element  (atoa  a)  for  each  a«A  and  an  element  cona(x.y) 
for  each  pair  of  lists  (x,y)«(L  x  L).  This  set  is  clearly  good  enough. 

It  turns  out  that  a  lot  of  interesting  new  types  can  be  defined  in  this  way,  for  example: 


—NOT1 _ 

zero  |  euc«  NOT!  » 


—BIN _ 

nil  I  node«  NOT!XBIN*BIN  » 


These  will  easily  be  recognisable  as  (a  set  isomorphic  to)  the  natural  numbers  and  the  set 
of  binary  trees  which  have  numbers  at  the  nodes. 

Not  all  such  specifications  denote  "reasonable”  sets,  though.  For  example: 

—S I LL  Y _ : _ , 

foo«  SILLY  »  I  baz«  SILLY  » 


might  have  nothing  at  all  in  it,  but  might  not 

In  general,  the  set  of  trees  specified  by 

—I _ , 

1  id,<<S,>>  |  ...  |  id„<<S„>> 
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is  nonempty  if  there  is  at  least  one  term  SI  -  Sn  in  which  T  does  not  appear  free  (or 
if  at  least  one  of  the  ids  stands  alone). 


The  functional  ids  -  are  sometimes  called  the  constructors  of  T;  those  ids  which  stand 
alone  are  called  around  elements  of  the  type.  The  around  constructors  of  T  are  those 
whose  Si  terms  do  not  contain  T  free;  elements  in  their  ranges  are  called  the  around 
trees  (or  structures  1  of  the  type.  The  remaining  constructors  are  called  proper 
constructors :  elements  in  their  ranges  are  called  the  proper  trees  (or  structures  >  of 
T. 


Technical  Note:  It  (almost.)  turns  out  that  this  kind  of  specification 
works  if  each  term  Si  m  which  T  appears  free,  has  a  certain 
property,  namely  that  the  function 

f  a  X  T  .  id,(  S,  ] 

is  monotonic  under  inclusion.  That  is,  given  two  subsets  X  and  Y  of 
some  hypothetical  set,  we  can  prove  that: 


XcY  -•  fj  X  ]  S  f[  Y  J 

Unfortunately  there  is  a  snaa :  sometimes  it  is  Just  not  possible  to 
fmd  a  larae  enough  m carrier* .  A  sufficient  condition  for  the 
existence  of  a  large  enough  carrier  is  to  restrict  the  S,  terms 
which  contain  T  to  one  of  the  following  finite  forms: 


T  x  ... 

FT 

T  . 

...  -**  T 


(  ...  may  contain  T ) 

(f  inite  subsets  of  T  J 
(  finite  mappings  from  T ./ 
( finite  mappings  to  T.) 
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S.8:  Reasoning  Methods  —  Structural  Induction 

The  most  important  reasoning  method  applicable  to  recursively  specified  sets  is  the 
principle  of  structural  induction.  We  will  illustrate  the  general  principle  of  this 
method  by  presenting  instances  of  it  which  are  appropriate  for  reasoning  about  the  sets  L, 
NUM.  and  BIN. 

The  list  induction  principle  is: 


%  , 


A 


% 

i 


l 


4 

■v 
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S:  P  L 


( 

Va: A  .  (atom  a)  e  S  a 
vll.  12:  S  .  conalll. 12)  6  s 
)  —  S=L 

If  a  property  holds  for  the  image  of  every  atom,  and  if  it  holds  for  lists  consed  from  lists 
for  which  it  holds,  then  it  holds  for  all  lists. 

The  Nun  induction  principle  is: 

S:  P  NUM 


( 

zero  s  s  a 
Vn:  S  .  (sue  n)«S 
)  —  s*mm 

If  a  property  holds  for  zero,  and  for  the  successor  of  every  NUM  for  which  it  holds,  then 
it  holds  for  all  numbers. 

The  BIN  induction  principle  is: 

S:  P  BIN 


( 

nil  e  s  a 

V  bl.  b2:  S;  n:  NUM  .  nods(n.  bl.  b2)  €  s 
)  S=BIN 

The  general  principle  is  a  little  tedious  to  sute  formally,  but  you  can  see  the  idea,  which 
can  be  summarised  as  follows  To  prove  that  a  property  holds  for  all  elements  of  a 
recursive  type  first  prove  that  all  the  ground  elements  of  a  type  have  the  property;  then 
prove  that  all  ground  trees  have  that  property;  finally,  under  the  assumption  that  all  its 
subtrees  have  the  property,  prove  that  each  proper  tree  has  the  property. 
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5.9:  Reasoning  Methods  —  Recursion  Principle 

Hitherto  we  have  specified  certain  functions  "recursively”  without  having  any  assurance 
that  the  specifications  were  satisfiable.  For  example,  the  following  is  a  specification  of  a 
function  which  is  intended  to  list  the  nodes  of  a  binary  tree  in  pre— order 


It  turns  out  that  a  large  class  of  recursive  specifications  of  total  functions  on  trees 
(including  the  one  above)  are  indeed  satisfiable. 

We  will  summarise  the  recursion  principle  by  giving  a  typical  instance  of  its  application, 
without  going  into  the  theory  behind  its  validity.  Suppose  T  is  defined  by 


consO  I  conal«X»  |  cona2«Y*T»  1  cona3«YxT*T» 


where  X  and  Y  and  Z  are  type  expressions  which  don't  contain  free  occurences  of  the 
identifier  T.  Suppose  we  are  also  given: 


gO:  0 

Gl:  X  -*  D 
H2:  Y*D  -*  D 
H3:  2*D*D  -*  D 

The  following  specification  of  f  is  satisfiable: 


f:  T 


f  consO  =  gO 

Vx: X  .  £ ( const  x)  *  Gl  x 

Vy:Y;  t: T  .  £(cona2(y, t) )  *  H2(y,  £  t) 

Vz:Z;  cl,c2:  T  .  £(cons3(z, tl , t2) )  *  H3(y,  £  tl,  £  t2) 


That  is  to  say,  there  really  is  a  total  function  which  behaves  as  specified. 


In  general  the  principle  states  that  in  order  to  specify  a  total  function  over  a 
recursively-defined  type  it  is  necessary  to  specify  its  value  at  all  ground  elements  of  the 
type,  to  specify  its  value  at  all  ground  trees  of  the  type,  and  to  specify  its  value  at  all 
proper  trees  of  the  type  In  this  latter  case  it  is  permissible  to  mention  the  value  of  the 
function  at  subtrees. 

In  our  definition  of  3 1  Nary  trees,  the  single  ground  element  is  nil.  and  the  single  (proper) 
constructor  is  node.  These  correspond  to  conaO  and  cons3  of  our  "typical  instance”.  The 
specification  of  flat  is  valid  because  <>  corresponds  to  gO,  and  the  function 

X  s,  n.  t  .  s  »  <n>  •  C 
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V.  *  *  i.V 


which  is  of  type 


seqlNUttl  x  HUIt  x  seqlNUMJ  -»  seqlNUfll 
corresponds  to  H3. 

In  our  notes  on  adequate  representations  for  finite  partial  functions  we  shall  apply  both 
the  structural  induction  principle  and  the  recursion  principle  extensivel". 

Appendix  I:  Partitions 

In  this  appendix  we  give  formal  definitions  of  disjointness  and  partitions. 


- 1 

disjoint:  P(a«q  (P  X)) 

partition*:  aeq  (P  X)  *-*  (P  X) 


V  SS:  saq  (P  X)  . 

SS  «  dia joint  «-* 

V  i,,  i,:doa  SS  . 

i,*i,  -•  (SS  i,)  n  (SS  ia)  »  () 

V  SS:  aaq  (P  X)  ;  S:  P  X  . 

SS  oartitiona  S  (SS  «  diajoint)  A  U(ran  SS)=S 

A  set  of  (sub)sets  of  X  is  disjoint  if  it  is  pairwise  disjoint;  that  is  if  no  two  distinct  sets 
have  a  nonempty  intersection. 

A  disjoint  set  SS  of  (sub)sets  of  X  partitions  a  (sub)set  S  of  X  if  its  (generalised)  union  is 

S. 


Appendix  II:  Injections 

Suppose  we  picture  each  relation  by  drawing  an  arrow  from  each  domain  element  to  the 
range  elements  to  which  it  corresponds.  Then  we  would  see  that  the  functional  relations 
are  those  in  winch  there  are  no  diverging  arrows  —  each  domain  element  maps  to  exactly 
one  range  element.  The  injective  functions  are  the  functions  in  which  there  are  also  no 
converging  arrows:  every  element  of  the  range  arises  from  just  one  element  in  the  domain. 
If  we  reverse  the  arrows  of  such  a  function  (take  its  inverse)  we  will  immediately  notice 
that  the  resulting  relation  is  itself  a  function  (no  diverging  arrows).  Thus  each  injective 
function  is  itself  a  function.  More  formally  we  define: 

(X.Y1 

X  >*♦  Y  a  <  £:X-»Y  1  f*  «  Y-*X  1 

X  >-*  Y  a  (  X»Y  )  n  (  X-+Y  ) 

The  two  signs  we  introduce  denote  respectively  the  partial  injections  and  the  total 
injections. 


B»U»WVM'»l  H'lL'  ll'tqiUltfULl  1  V”W  V  V  * 


V 

dfi 


Appendix  III:  Syntax 

The  following  is  a  summary  of  the  syntax  of  those  parts  of  the  language  we  have  so  far 
explained. 


i 

>; 

V, 


Pi 

„% 

< 


A 

'  h 

V! 


IB 


3? 


*  a 


r. 


Tern  : : =  Id 

(  Signature  I  Predicate  .  Tera  > 
{) 

<  Termlist  ) 

(  Termlist  ) 

Tera  *  Tera 

P  Tera 

F  Tera 

Tree 

ft  Tera 

FnTera  Tera 

Tera  FnTera  Tera 

X  Signature  |  Predicate  .  Tera 

Tree  : : »  Branch 

Branch  I  Tree 

Branch  : : =  Id 

Id«Tera» 


Predicate  3  Signature  .  Predicate 

V  Signature  .  Predicate 

Tera  *  Tera 
Tera  «  Tera 
Tera  *  Tera 
Tera  c  Tera 
Tera  s  Tera 
Predicate  *  Predicate 

Predicate  v  Predicate 

Predicate  -•  Predicate 
Predicate  «•»  Predicate 
■*  Predicate 
Tera  RelTera  Tera 

RelTera  :  •• »  Tera 
FnTera  Term 


Signature 

TypeAttr 

TeraList 

IdList 


TypeAttr 

TypeAttr:  Signature 
Idhist:  Tera 

Tera 

Tera,  Termlist 
Id 

Id.  Idlist 


Defn  (IdListl  TeraeTera 

(IdLietl  Signature  I  Predicate 
( Idlist 1  Id  a  Tree 


set  comprehension 
empty  set 
set  extension 
tuple 

product  constructor 

subset  constructor 

f. in  tie  subset  constructor 

size 

function  application 
infix  function  application 
lambda  abstraction 


disjoint  union 

ground  element 
tree  constructor 

existential  quant rf  ication 

universal  quant  if  ication 

equality 

membership 

negation  of  equality 

proper  subset 

subset 

conjunction 

disjunction 

implication 

logical  equivalence 

negation 

inf  ix  relation  membership 


Syntactic  Equivalence 
Constant  Specif  ication 
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^  ,v.\  a..^  a-  >  A_!^lLAJL.,VW.j  . 


Hddresc. 


Bernard  Sufrin.  Ext  281 


12: 15: 22 
12:15:22 
12: 15 : 25 
12: IS: 28 
12: 15: 30 
12:  IS:  33 
12: IS: 54 
12: 16:24 
12:16:24 
12:16:33 
12:16:39 
12:16:43 
12: 16:54 
12:18:19 
12: 18:20 
12:18:29 
12:18:29 
12:18:54 
12:19:01 
12:19:01 
12: 19:01 
12:19:02 
12:19:57 


Connected  to: 

In  service  of: 

Rece i v i ng: 

Receiving: 

Rece i v i ng: 

Receiving: 

Rece i v i ng: 

Runn i ng: 

Print  indirect  from: 
Context  from: 
qpOoc : 

Pr i nt i ng: 


Connect  mg: 
Connect ing: 

Time  Service: 
Reserved  until: 
IService: 
Reserved  until: 


Martin  R.  Raskovsky  (x294) 

3F00  0000.0200  4165 
Sys:  Serv i ce>3AfiB_41Fl  AD99  F5E7 
Sys :  Ser  v  i  ce>38A8_00OFlPO992AO3S; 
Sys: Serv i ce>38AB  00DF.AQ993EAD3 
Sys:  Serv  i  ce>39AB3074_AD99_2C67% 
Sys: Serv , ca>39AB_6074_AD99  2C67 
qPrint  8Sys:Service>Pr int.Me 

Sys: Serv i ce>Pr i nt . Me 

Sys: Serv i ce>38AB_00DF_AD99_EAD3 

Entry 

Sys : Ser v i ce>39A8_60?4_AD99_2C67 

Printed  10  pages 

Exit 

Exit 

To  Network  via  Data  Switch 
To  Time  Service 
12:19:01  07-Sep-94 
12:49:01  07-Sep-84 
Entry 

12:49:58  07-Sep-84 


12: 19:58 
12:19:58 
12:20:01 
12:20:08 
12:20:15 
12:20:20 
12:21:03 
12:21:42 
12:22:05 
12:22:29 

12l23il3 

12:23:38 

12:24:03 

12:24:27 

12:24:50 

12:25:19 

12:25:4? 

12:26:06 

12:26:27 

12:26:27 

12:26:37 

12:26:42 

12:26:46 

12:26:52 

12:28:26 

12:28:31 

12:29:31 

12:29:36 

12:30:30 

12:30:34 

12:31:35 

12:31:40 

12:32:34 

12:32:38 

12:33:47 

12:33:51 

12:34:30 

12:34:31 

12:34:40 

12:34:40 


Connected  to: 

In  service  of: 

Rece i v i ng: 

Receiving: 

Receiving: 

Rece i v i ng: 

Receiving: 

Receiving: 

Receiving: 

Receiving: 

Receiving: 

Receiving: 

Receiving: 

Rece i v i ng: 

Rece i v i ng: 

Rece i v i ng: 

Receiving: 

Rece i v i ng: 

Rece i v i ng: 

Runn i ng: 

Print  indirect  from: 
Context  from: 
qpDoc: 

Pr  i nt i ng: 

Pr  mt  mg: 

Print i ng: 

Printing: 

Pr  i  nt i ng: 

Pr  i nt i ng: 

Pr i nt i ng: 

qpDoc : 
qPr i nt  : 


Bernard  Sufrin.  Ext  2B1 
4000  0000.0200  5766 
Sys: Serv i ce>3AAB_DFCF  AD99.888B 
Sys: Serv i ce>F7AA_AA9A  AD99  6281% 
Sys: Serv ice >F?AA_AA9A~AD99 .6281 
Sys: Serv i ce>F9AA_0070_AO99_88SE* 
Sys : Ser  v i ce  >F9AA  0070  AD99 _S8SE 
Sys:  Ser  v  i  c«>FCft0F90D99:£EA9% 
Sys: Serv ice>FCAA3FB0  A099TEA9 
Sys: Serv i ce>2DA8_81C6lAD99_90A8% 
Sys: Serv i ce>2DA8_81C6_AD99  90A8 
Sys:  Serv  i  ce>2FA8_0F2F_AD993ClA% 
Sys:  Serv .  ce>2FA8_0F2F_AO995ciA 
Sys: Servi ce>31A833401_A099_2DCl% 
Sys: Serv i ce>31A8  8401.A099I2DC1 
Sys : Ser v i ce>33AB_90S2_AO99_0243% 
Sys: Serv i ce>33A8_9052_AD99_0243 
Sys: Serv i ce>35A8_03F3_AD99_43E9% 
Sys : Serv i ce>35A8.03F3_AO99  43E9 
qPrmt  8Sys : Serv i ce>Pr  int.Me 

Sys: Serv ice>Pr int.Me 

Sys: Serv i ce>F7AA_AA9A_AD99_S281 

Entry 

Sys : Serv i ce>F9AA_0070_AD99_885E 
Printed  8  pages 

Sys : Serv i ce>r CAA.BFB0_AD99.FEA9 
Printed  7  pages 

Sys: Serv i ee>2DAB_81CS_AD99_90AB 
Printed  6  pages 

Sys : Serv i ce>2FA8_0F2F_AD99_ECl A 
Printed  7  pages 

Sys: Serv , ce>3lAB_8401_AD99_2DCl 
Printed  6  pages 

Sys: Serv i ce)33AB_90S2_AD99_0243 
Pr inted  8  pages 

Sys: Serv i ce>d5A8_03F3_AO99_43E9 
Printed  4  pages 
Exit 
Ex  1 1 
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Introduction 


When  specifications  are  written  in  the  Z  notation,  two  complementary  formal  languages  are 
employed:  the  mathematical  language  and  the  schema  language.  The  mathematical  language  is 
based  on  standard  set  theory,  but  is  "strongly  typed”  in  a  way  which  most  Computer  Scientists 
will  find  familiar.  The  schema  language  supports  the  systematic  presentation  of  large-scale 
system  specifications,  or  families  of  specifications,  which  embody  material  defined  in  the 
mathematical  language. 

Z  has  evolved  a  good  deal  since  its  introduction  in  1979  [Abrial],  and  this  handbook  is  an 
attempt  to  capture  the  state  of  the  mathematical  language  as  it  stands  in  mid-1984.  For  an 
introduction  to  the  mathematics  which  underlies  Z  the  reader  may  consult  any  of  the  material 
in  Section  1  of  the  bibliography.  For  an  introduction  to  the  style  and  practice  of  formal 
system  specification  which  Z  supports  see  section  2  of  the  bibliography,  which  is  a  list  of  case 
studies  which  for  the  most  part  use  the  present  dialect. 


1 

Basic  Notation 


§1.0  Preliminaries 

In  what  follows  we  use 

claa*  : : - 

dof, 

dof. 


to  define  a  new  syntactic  class  clasa.  A  definition  in  this  form  should  be  taken  to  mean  that 
wherever  a  phrase  of  class  clasa  is  required,  it  can  be  supplied  in  one  of  the  forms  d«£,  . . . 
da£. 

The  principal  syntactic  classes  we  shall  define  are  signature,  tarn,  predicate.  In  specifying 
syntactic  equivalences  we  shall  assume  that  the  syntactic  variables 


t,  t,,  tj,  ...  t. 

range  over  terms 

id,  id,.  id,.  . . .  id, 

v.  V,.  V,  .  .  .  V, 

range  over  symbols,  as  do 

aig,  aig,.  eiga,  ...  aig„ 

range  over  signatures 

P.  Pi.  Pa  •••  P. 

range  over  predicates 

F.  F„  F. 

range  over  terms  which  denote  functions 

R»  R,.  Rj 

range  over  terms  which  denote  relations 

T.  T„  T„  ...  T. 

range  over  terms  which  denote  sets 

The  lexical  structure  of  the  class  of  syabols  is  left  undefined,  but  includes  all  sequences  of 
alphanumeric  characters,  and  all  peculiar  shapes  which  the  artistically  inclined  may  care  to 
think  up  to  represent  mathematical  objects  mnemonically. 

When  specifying  syntactic  equivalences,  the  symbol  ^2^  between  two  patterns  a  and  b  means  "a 
and  b  arc  defined  to  be  syntactically  equivalent*.  To  be  more  precise,  if  by  substituting 
appropriate  phrases  for  the  syntactic  variables  in  the  pattern  a  we  match  a  phrase  of  the 
language,  then  this  phrase  may  be  replaced  by  the  phrase  formed  from  the  pattern  b  by 
making  the  same  substitutions  for  syntactic  variables.  Likewise  if  b  matches  a  phrase  of  the 
language,  then  the  phrase  may  be  replaced  by  a  suitably  modified  a.  (See  note  3  of  §L1  for  a 
simple  worked  example). 

Technical  Note-  As  presented  here  the  syntax  appears  to  be  ambiguous,  for 
except  in  two  cases  we  have  not  mentioned  the  binding  power  (precedence) 
of  the  symbols  of  the  notation.  Nevertheless,  since  the  symbols  used  as 
operators  are  always  introduced  by  signatures  which  indicate  their 
set-theoretic  type,  the  structure  of  compound  phrases  can  usually  be  inferred 
from  context,  and  in  awkward  cases  parentheses  may  be  employed  to  make 
the  structure  explicit 


§1.1  Signatures 

A  type  declaration  introduces  a  new  variable  or  a  new  constant,  associates  it  with  a  symbolic 
identifier,  and  ascribes  to  it  a  type,  from  which  may  be  deduced  the  values  which  it  is 
permitted  to  take.  A  signature  is  a  sequence  of  type  declarations. 

Syntax: 

signature  : : = 

dec! 

decl  ;  signature 

decl  : : = 

symbol  :  tern 

Syntactic  Equivalence: 

Id,  a  id,  ...  id,  -  T  -  id,  :  T;  id,  •  T;  ...  id,  i  T 

Examples: 

carr iagereturn:  CHAR 

size:  Number;  weight:  Number;  contents:  P  THING 

size:  Number 

weight:  Number 

contents:  P  THING 

factor:  prises  «-»  Number 

carriagereturn,  linefeed:  CHAR 

N  x  N  — •  N  “n 

adder:  N  — ♦  N  — »  N 

Notes: 

A  declaration  may  be  presented  in  vertical  form,  in  which  case  the  semicolons  between  type 
attributions  may  be  omitted,  and  each  type  attribution  appears  on  a  new  line. 

131  A  term  which  appears  to  the  right  of  the  colon  in  a  type  attribution  must  denote  either  a 
type,  or  a  set  whose  carrier  type  can  be  determined.  (See  Appendix  1) 

131  This  signature  is  syntactically  equivalent  to  carriagereturn:  CHAR;  linefeed:  CHAR  the 
substitutions  being:  CHAR  for  T,  carriagereturn  for  id,,  linefeed  for  id,  (and  2  for  n). 

141  When  introducing  a  function  symbol  whose  name  is  not  composed  of  alphanumerics,  it  is 
customary  to  indicate  its  fixity  by  putting  underline  symbols  in  the  places  where  its  argument 
or  arguments  will  appear.  This  signature  introduces  the  infix  symbol  _+_,  which  maps  pairs  of 
numbers  to  numbers. 

1,1  This  signature  introduces  a  function  symbol,  adder,  which  maps  a  number  into  a  function 
from  numbers  to  numbers.  The  function-arrow  signs  are  right  associative  so  the  term  A— *B— *C 
should  be  parsed  A  -*  (B  -»  C>.  Function  application,  denoted  by  juxtaposition,  is  left 
associative  (see  §1.2). 


§1.2  Terms 

A  term  is  a  phrase  of  the  mathematical  language  which  corresponds  intuitively  to  a  set  or 
to  an  element  of  a  set. 

Syntax: 

t*ra  : : » 

symbol 

(  eignatur*  |  predicate  .  tera  ) 

<  tera,  tera,  —  tera  ) 

(  tera,  tera,  . . .  tera  ) 
tera  *  tera  *  . . .  *  tera 
P  tera 
tera  tera 
u  tera 

branch  f  branch  _  I  branch 

branch  : :  => 

symbol 

ayabol«tera» 

Note: 

Function  application  is  denoted  by  juxtaposition,  which  associates  to  the  left  The  term 
add  a  n  therefore  denotes  the  application  ((add  a)  n).  Of  course  nothing  forbids  the  use 
of  parenthesis  around  arguments,  as  for  example  in  delete(foo). 

Syntactic  Equivalences: 


set  comprehension 
finite  set  extension 
n-tuple 

product  set  (n-tuples) 
power  set  (subsets) 
function  application 
arbitrary  choice  from  a  set 
disjoint  union 


v,:Tf;  V,:T,;  ...  v„:T„  I  p  v,iT,;  va:Ia;  ...  v„:T.  |  p  .  (v,  ...  v.) 


slg  .  t 


aig  |  true  .  t 


(  v, :  T, !  va:Ta;  ...  v„:T„  ) 


^  X,  *  T»  *  ...  X. 


(  t  .  Big  I  p  ) 

(  t  .  aig  > 
t,  —  t, 
t,  F  ta 

X  v, : T, i  va:Ia;  .  .  .  v„:I„ 
t  uhere.  aig  I  p 


P 


(  Big  I  p  .  t  > 

^  (  Big  .  t  ) 

(t,,  ta) 

F(t,,  ta) 

t  ^  <v,:X,:  VJ  :Xa;  •••  vB:  I„  Ip.  (v, 

^  u  (  sig  I  p  .  t  ) 


iai 
is  > 
Ml 

i*i 


Notes: 

In  situations  where  the  form  signature  I  predicate  .  tera  appears,  the  term  may  be 
omitted  when  it  is  a  tuple  consisting  of  the  variables  of  the  signature,  as  may  the  predicate 
if  it  is  identically  true. 

1,1  The  sign  >-*  is  pronounced  “to",  or  “maps  to";  terms  of  this  form  appear  in  the 
construction  of  relations,  (see  Relations,  §2^) 

Infix  notation  for  function  applicatioa  (see  Functions,  §23) 

141  A  function  is  just  identified  with  the  set  of  domain-range  pairs  which  it  maps  between,  (see 
Functions,  §2.3) 

This  permits  local  definitions  to  be  made 


> 


Examples: 

<  n:N  |  divisor*  n  *  <53.  73)  .  n 

<  n:N  1  divisor*  n  *  (1.  n)  ) 

(  i.j:  H  1  i+j  «  prisss  .  (i.j)  > 

{  i.j:  M  1  i+j  «  prisss  ) 

(53.  73) 

<i.  j.  k> 

N  x  N  x  N 
(  i.j.k:  N  ) 

P  (53.  73) 

(> 

P  () 


a 


U  (  x:H  |  x3  *  64  .  x  ) 
u  {  x.y:  N  1  x«42  a  y*45  .  x*-y*  ) 
psir<<M  x  N>>  |  tripl#<<M  x  N  x  ft> > 
blus  I  whies  |  grssn 


Interpretation: 

"*  The  squares  of  all  numbers  divisible  only  by  S3  and  71 
111  The  numbers  which  are  only  divisible  by  themselves  and  1  (the  primes). 
The  set  of  all  pairs  of  numbers  whose  sum  is  a  prime. 

Same  as 


It  ) 

13) 

<31 

141 

IS) 

IS) 

17) 

IS) 

IS) 

IftO) 

lift  ) 

t<>> 

113) 

114  ) 

US) 


19 ’  The  set  whose  two  elements  are  53  and  73 

10 1  The  triplet  (3-tupie)  i  j  k. 

trt  The  set  of  ALL  triplets  of  numbers. 

'•*  Same  as 

*91  The  set  of  all  subsets  of  (53.  73);  that  is  <  ().  (53).  (73) t  (53.73)  ). 
ii0t  The  empty  set 

,in  The  set  of  all  subsets  of  the  empty  set;  that  is  (  ()  ). 

■,*1  A  number  whose  cube  is  64;  either  4  or  -4. 

<l3>  The  difference  between  42  cubed  and  45  squared. 

,|4’  The  disjoint  union  of  the  pairs  of  numbers  and  the  triples  of  numbers.  (See  Appendix  1). 
,49,  The  enumerated  type  whose  elements  are  blue,  white,  and  green.  (See  Appendix  1). 


a 


viy.v 


%i,3  Predicates 

A  predicate  is  a  phrase  of  the  mathematical  language  which  corresponds  intuitively  to  a 
statement  (about  sets  or  elements  of  sets),  which  may  or  may  not  be  provable. 

Syntax: 

predicate  : :  = 

-  predicate  negation 

predicate  a  predicate  conjunction  (and) 

tern  =  term  equality 

term  «  tera  set  membership 

tern  s  tera  subset 

tera  syabol  tera  relation  holds  between  terms 

3  signature  .  predicate  existential  quantification  (for  some) 

predicate  uhert>  definition  local*  definition 

Note: 

*•’  It  is  customary  to  underline  a  symbol  composed  only  of  alphanumeric  characters  when 
it  is  used  as  an  infix  operator. 

Syntactic  Equivalences: 


Pi  v  Pa 

P,  A  'Pa> 

disjunction  (or) 

Pi  “*  Pa 

C-  Pi>  *  Pa 

implication  (if-then) 

Pi  ~  Pa 

— 

'Pi  “*  Pa>  A  <Pa  -»  P,) 

logical  equivalence 

t,  *  ta 

'(t,  =  ta) 

inequality 

t,  *  ta 

— 

-(t,  «  ta) 

nonmembership 

t,  C  ta 

— 

(t,  S  t*  )  A  (t,  #  ta) 

proper  subset 

( V  aig  .  p) 

— 

-  (  3  Big  .  (-  p)  ) 

universal  quantification  (for  all) 

3,  Big  .  p 

= 

(3  sig  .  p)  a 
(V  v,,va:(Big  |  p>  .  v,*v,) 

existence  of  a  unique  element 

V  Big  I  p,  . 

Pa 

—  V  Big  .  p,  -*  p. 

It  1 

3  Big  |  p,  . 

Pa 

—  3  Big  •  P,  *  p, 

iai 

p,  a  pa  a  _  p 

ft 

—  Pi 

Pa 

P» 

(3) 

t,  R  ta  ^  (t,.  ta)  €  R  ,4’ 

t,  R,  ta  Ra  t,  ^2;  (t,  R|  tjl  A  (ta  Rj  t3) 

Notes: 

The  left  band  side  of  this  equivalence  is  read:  "pa  holds  for  all  _  such  that  p,”. 

The  left  band  side  of  this  equivalence  is  read:  "p,  holds  for  some  -  such  that  p," 

** ’  A  long  sequence  of  conjunctions  may  be  written  vertically  provided  that  the  indentation 
established  for  the  first  predicate  is  inherited  by  the  following  predicates. 

The  left  hand  side  is  sometimes  read  as  "R  maps  t,  to  taa.  In  Z  a  relation  is  identified 
with  the  pairs  of  elements  between  which  it  holds.  (See  §2.2) 


Examples: 

-(369  e  primes) 

( mydog  €  has fleas )  a  (age  mydog  >  14) 

((weather  here)  =  raining)  v  (here  =  Paris) 

((weather  here)  ®  awful)  —*  (here  =  Oxford) 

(x  divides  y)  **  (3  z:N  .  x  *  z  =  y) 

EUROPE  C  STATE 
(369,  7)  C  prises 

3  state: EUROPE  .  state^UK  a  (head  state)  descendant  Victoria 
V  state: EUROPE  .  state  €  EEC 

3  state: EUROPE  |  state^UK  (head  state)  descendant  Victoria 

V  state  .-STATE  I  state  e  EUROPE  .  state  «  EEC 

V  p:  PERSON  . 

father  p  «  PERSON 
mother  p  «  PERSON 
children  p  c  PERSON 

Bernard  descendant  Samuel  uherr  descendant  »  child* 


Interpretatiorc 

369  is  not  a  member  of  the  set  of  primes. 

Mydog  is  a  member  of  hasfleas  and  its  age  is  greater  than  14. 

131  The  weather  here  is  raining  or  here  is  Paris. 

<4>  If  the  weather  here  is  a  member  of  awful  then  here  is  Oxford. 

x  divides  y  if  and  only  if  there  is  a  number  z  whose  product  with  x  is  y. 

EUROPE  is  a  subset  of  the  set  STATE 

,T>  The  set  whose  two  elements  are  369  and  7  is  a  subset  of  the  set  of  primes. 

There  is  a  sute  in  EUROPE  which  is  not  the  UK  and  whose  head  is  a  descendant  of 
Victoria. 

'*’  All  states  in  EUROPE  are  members  of  EEC 
'•0'  (Same  as  8) 

(Same  as  9) 

The  father,  mother,  and  children  of  all  persons  are  persons. 

"3>  Bernard  is  in  the  relation  descendant  with  Samuel,  where  descendant  is  defined  to  be 
the  transitive  closure  (see  §2.7)  of  the  relation  child. 


§1.4  Definitions 

Constants  are  defined  either  by  syntactic  equivalence,  or  by  axiomatic  specification.  Generic  (ie 
families  of  t  y  pe- par  am  e  tensed)  definitions  are  preceeded  by  a  sequence  of  type  identifiers, 
which  indicate  the  formal  type  parameters  of  the  definition. 

Syntax: 

definition 

axiomatic 

syntactic 

generic 


axiomatic 


syntactic 


signature 

predicate 

term  a  term 

mvmhol 

term 

generic  t symbol,  ...1  definition  '*’ 

Note: 

Generic  definitions  specify  families  of  constants;  see  examples  and  below. 


Examples: 


poly:  N  — ♦  N 


V  x: N  .  poly  x  *  x*  ♦  2x* 


processor spernode :  N 

1 

7  <  processorspernode  <  19 

primes,  squareprimes:  P  N 


primes  =  <  n:N  I  divisors  n  =  <1.  n>  > 


squareprimes  *  <  n: primes  .  n9  ) 


141 


impossible:  N 


V  n: primes  .  impossible  >  n 


NumberPair  a  N  x  N 
. _ NumberPair  _ 

|l N  X  N 


1(1 


■■I 


Interpretation 

The  symbol  poly  denotes  a  function  which  maps  numbers  to  numbers.  Every  number  maps 
under  poly  to  the  sum  of  its  square  and  twice  its  cube. 

<a’  The  symbol  processorspernode  denotes  a  (constant)  number  between  seven  and  nineteen. 

111  The  symbols  primes  and  squareprimss  denote  constants:  primes  is  the  set  of  all  numbers 
divisible  only  by  1  and  themselves;  squareprimes  is  the  set  of  numbers  generated  by  squaring 
each  prime. 

141  The  symbol  impossible  denotes  a  number  which  is  larger  than  or  equal  to  every  prime. 
This  is  an  unsaiisfiable  specification,  of  course,  since  there  is  no  such  number. 

'* ’  The  symbol  NumberPair  is  syntactically  equivalent  to  the  term  N  *  H 

Same  as  '•*. 

Further  Examples: 

. _  PrimaryColour  _  ,T‘ 

|  Red  |  Blue  |  Yellow 


[XI 


_  u  _ 

:  P  X  * 

P  X 

-*  P  X 

1 

»  8,. 

8,:  P  X 

•  "I 

U  B,  x  {  X:X 

X  €  B, 

V  X  «  a,  > 

[XI 

l 

flatten:  seq  Cseq  X)  — »  seq  X 


flatten  <>  ■  <> 

V  x:seq  X:  a: seq  (seq  X)  . 

flatten(x  *  s)  =  x  «  (flatten  s) 


flat. 0 
flat. 1 
flat. 2 


Interpretation 

PrimaryColour  is  a  type  which  contains  exactly  three  elements,  named  Red,  Blue, 
and  Yellow.  (See  Appendix  I). 

This  is  a  family  of  definitions.  For  every  type  X,  the  infix  symbol  u,,,  denotes  union  for 
sets  of  elements  from  X.  This  is  a  function  which  maps  pairs  of  sets  to  sets.  The  result  set  and 
the  argument  sets  are  all  subsets  of  X.  It  is  customary  to  omit  the  subscript  when  using  the 
operator  in  a  term  since  it  can  be  inferred  from  the  types  of  the  operands.  For  example,  if  we 
have 


gold:  P  FISH 
angel:  P  FISH 


£ 


§ 


then  the  u  in  the  term  gold  u  angel  denotes  the  union  function  for  sets  of  elements  of  type 
FISH,  ie:  For  further  details  see  Appendix  L 


■ 


^  * 


s 


ft 


ft 


v  ^ 

i 


This  specifies  a  family  of  functions  on  sequences  of  sequences.  In  order  to  be  able  to  refer 
(for  example  within  proofs)  to  the  different  parts  of  the  specification  we  have  labelled  them. 
This  is  an  informal  practice  which  can  improve  the  readability  of  documents  when  used 
judiciously. 

§1.5  Chapters 

As  yet  there  is  no  formal  way  of  modularising  a  Z  document.  Present  practise  is  to  divide 
the  material  presented  in  a  specification  into  named  chapters.  Bach  chapter  consists  of  some 
symbol  definitions  explained  by  prose,  together  with  some  theorems  (see  §L6).  Although  it  is 
rare  for  constants  defined  in  different  chapters  to  be  given  identical  names,  any  confusion 
between  such  constants  is  resolved  by  qualifying  their  names  with  the  name  of  the  chapter  in 
which  they  were  defined.  For  example:  if  in  a  single  Z  text  we  have  chapters  named  SIMPLE 
STORAGE  and  SAFE  STORAGE,  each  of  which  defines  something  named  STORE,  and  if  we  wish  in 
a  subsequent  chapter  to  refer  to  both  constants,  then  we  use  the  symbol:  SIHPLESTORAGE§STORE 
to  denote  the  former  and  the  symbol  SAFESTORAGE§STORE  to  denote  the  latter. 

It  is  also  customary  for  Z  documents  to  be  self-contained.  Any  symbols  which  are  referred  to 
in  a  text  are  to  be  found  explained  in  a  chapter  (perhaps  an  appendix)  of  the  document  In 
order  to  simplify  matters  it  is  assumed,  unless  otherwise  indicated,  that  the  standard  material 
of  section  2  of  this  document  (on  sets,  relations,  functions,  numbers,  sequences  iteration  and 
transitive  closure)  is  present  Constants  defined  in  these  standard  chapters  may  freely  be  used 
anywhere  in  a  document 


s 


§1.6  Theorems 

A  theorem  is  a  statement  about  the  definitions  which  appear  in  its  chapter  and  the  chapters  to 
which  it  refers.  The  statement  is  an  assertion  that  a  certain  predicate  has  been  proved  from  the 
definitions  themselves  together  with  the  rules  of  reasoning  of  Z  In  order  to  be  able  to 
refer  to  theorems  within  prose  or  from  proofs  which  use  them,  we  sometimes  label  them  with 
identifiers  or  numbers. 

Syntax: 

theorem  : : * 

*-  predicate 
hypothesis  *-  predicate 

hypothesis  : : * 

signature 

signature  |  predicate 
hypothesis;  hypothesis 

Examples: 

•-  3  «  prises 
x:  N  •-  xtl  c  N 

x,y:N  1  x^Ojty  t-  tpred  x)  =  (pred  y)  ^  (x=y) 

Notes: 

‘"A  theorem  doesn*t  amount  to  an  assertion  that  we  wish  we  could  prove  a  certain  predicate, 
or  that  we  think  that  we  might  be  able  to  but  haven’t  quite  enough  to  time  to  go  through  the 
motions.  Such  a  statement  is  usually  called  a  conjecture,  and  may  be  written  with  a  ?*-  sign  in 
place  of  the  *-  sign.  For  details  of  the  way  in  which  proofs  should  be  presented,  see  Appendix 
2. 

1,1  This  theorem  reads  "given  a  natural  number  x,  we  can  prove  that  x+1  e  IT. 

This  theorem  reads  "given  natural  numbers  x  and  y,  which  both  differ  from  zero,  we  can 
prove  that  (prad  x)  =  (prsd  y)  — »  (x=y)“. 


2 

Standard  Chapters 


§2.1  Sets 

2X1  There  ire  no  "built-in"  sets  in  Z.  Despite  this,  it  is  customary  to  assume  that  the 
symbol  N  denotes  the  set  of  natural  numbers  (nonnegative  integers).  In  fact  H  together 
with  the  usual  operations  on  it,  can  be  defined  within  Z  (see  Appendix  1  for  details). 

It  is  also  customary  to  preface  a  Z  document  with  a  form  of  words  such  as 

"let  PERSON  denote  the  set  of  all  persons,  and  let  CITY  denote  the  set  of 

all  cities  —  we  need  not  go  into  the  internal  structure  of  these  sets  any 
f  urther". 

This  form  of  words  can  be  interpreted  as  meaning  "we  could  give  constructive  definitions 
of  PERSON  and  CITY,  but  such  definitions  would  simply  be  a  distraction  at  present".  The 
symbols  PERSON  and  CITY  are  said  to  denote  "given  sets"  under  these  circumstances,  and  a 
document  with  such  a  preface  characterises  a  family  of  specifications,  one  for  each  possible 
constructive  definition  of  the  "given  sets". 

2.1.2  For  any  set  T,  the  term  P  T  denotes  the  set  of  all  sets  whose  members  are  drawn 
from  T,  ie  the  set  of  all  subsets  of  T.  Nothing  can  be  a  member  both  of  T  and  of  P  T. 

»-  T,  €  (P  T,)  •-  I,  t  I, 

(T,cTt)  a  (T,cT.)  «-•  (T,*T#) 

2X3  For  any  set  T,  the  term  F  T  denotes  the  set  of  all  finite  subsets  of  T.  A  set  of 

elements  is  finite  if  there  is  a  one-one  correspondence  between  its  members  and  an  initial 

segment  of  the  natural  numbers. 

2X4  For  any  sets  T,  . . .  T„  the  term  T,  *  . . .  *  T.  denotes  the  set  of  all  n-tuples,  such  as; 

It,,  .  • .  ■  t,) 

These  are  characterised  by 

►-  (t, . t.)«(T,  *  ...  x  T„)  «-*  t,€T,  a  ...  a  t,«T, 

Nothing  can  be  a  member  both  of  one  of  the  sets  T,  and  of  T,  x  . . .  x  t„. 

2X3  For  any  sets  T,  . . .  T„  and  any  distinct  symbols  id,  ...  id.  the  term 
id,<<T,»  I  ...  I  id,<<Tn>> 

denotes  the  "labelled  disjoint  union”  of  T,  . .  T„.  Nothing  can  be  a  member  both  of  one 
of  the  sets  T,  and  of  the  disjoint  union  This  is  a  set  which  contains  exactly  one  element 
for  each  of  the  elements  in  T1P  one  for  each  of  the  elements  of  T„  ...  and  one  for  each 
of  the  elements  of  T.  but  no  more.  The  symbols  id,  . . .  id,  denote  injective  functions 
which  map  to  and  from  the  disjoint  union  (see  section  5  of  [Sufrin]  for  more  details). 

2.1.5  For  any  distinct  symbols  id,  ...  id,  the  term  id,  I  id,  |  ...  id,  denotes  the 
"enumerated  type"  which  contains  exactly  the  elements  id,  ...  id,. 


J 


§2.2  Relations 

For  any  sett  T,  and  T„  the  set  of  all  binary  relations  between  ?,  and  Ta  is  defined  to  be 
the  set  of  all  sets  of  ordered  pairs  from  T,  *  T,.  When  elements  t,  and  ta  are  related  by 
R,  we  sometimes  say  that  R  maps  t,  to  tT  The  domain  of  a  relation  R  is  the  set  of  all 
elements  which  are  mapped  to  something  by  R;  the  range  of  R  is  the  set  of  all  elements  to 
which  R  maps  elements  of  its  domain.  The  inverse  of  a  relation  R,  written  R‘‘,  has  the 
ordered  pairs  of  R  reversed. 


Definition: 

IT..  Tjl 

T,  *-*  T,  •  P(T,  x  Ta) 

Syntactic  Equivalences: 

t,  •-»  t*  ^  (t,.ta) 

Definitions: 

IT,.  Tal  R-(T,«->Ta)  ^ 

don  R  «  (  x:T,  I  Oy:T,  .  xRy)  > 

ran  R  «  (  y:Ta  1  (3x:T,  .  xRy)  ) 

R'*  •  (  (y*~*x)  .  y: Ta:  x:T,  I  xRy  ) 

t,  R  ta  o  (t,.ta)€R 


Note: 

This  is  a  context-dependent  set  of  definitions;  it  signifies  that  for  any  sets  T,  and  Ta  the 
four  syntactic  equivalences  hold  for  all  binary  relations  R  between  sett  T,  and  Tr 

Examples: 

L  For  each  set  S  of  elements  of  T,  the  identity  relation  between  pairs  of  elements  of  S  is 
defined  by: 


so,  for  example, 

id  (3.4.5)  *  (  3*-*3,  4*-*4,  5>-*5  ) 

Notice  that 

S:  PI  »-  (id  S)  =  (id  S>  1 

2.  H  *-»  N  is  the  set  of  all  relations  between  pairs  of  numbers.  An  example  of  such  a 
relation  is 


Which  can  be  characterised  by  any  of  the  following,  logically  equivalent  axioms: 
=  (  n,,  n,:N  I  (3  d:N  .  n,*d=na)  (n,  •  na)  ) 


8 


I 


=  ^  nt*  n2:N  |  (i  d:N  .  n,»d=n2)  ) 

V  n,  ,n2:N  . 

n»  <  ••  3  d:N  .  n,+d=n2 

3.  Another  binary  relation  betwen  numbers  is  the  finite  binary  relation: 
<  0*-*I,  1*— *2,  2*— »3,  3"-*3,  o>— *0  ) 


r . 

■Cr 


Theorems: 


R:  T,«-»T2  *-  ( R‘‘ )  *•  >  R 
R;  T,«-*T2  *-  doaCR'M  =  ran  R 
R:  T,«-»T2  •-  ran(R'‘)  s  doa  R 


Vi. 


•  1 


R 


rii 


a 


'A 

A 


i 


VuVlWlj 


tici 


W'l 


ryw 7^  btt*  u  >v*vr 


§23  Functions 


2JJ  Noution  for  Functions 

The  set  of  partial  functions  from  T,  to  Ta  is  the  set  of  relations  between  T,  and  Ta  which 
map  elements  of  their  domain  to  a  single  element  of  their  range.  A  partial  function  is  said 
to  be  total  from  T,  if  its  domain  is  all  of  T,.  A  function  is  said  to  be  a  finite  mapping 
from  T,  if  its  domain  is  a  finite  subset  of  Tt. 

i 

IT,.  Tal 

T,  -+♦  Ta  •  <  R:T,«->Ta  |(V  x:Tt;  y,,ya:Ta  .  xRy,  *  xRya  y,=ya>  ) 

T,  -»  Ta  *  {  f:T,-*Ta  I  do*  f  »  T,  ) 

I,  Ia  »  (  f:T,-*Ta  |  doi  £  «  f  I,  ) 


I 


An  injective  function  is  one  whose  inverse  is  also  a  function.  We  use  the  following 
symbols  to  denote  the  partial,  total  and  finite  injections 


y. 


A- 


\ ; 


V 


t 

'A 

V. 


IT,.  T,1 

T,  >♦♦  Ta  e  (  f :  T,-**Ta  I  f"  «  Ta-«T,  ) 

T,  >-»  Ta  «  (T,  >♦*  Ta)  n  (T,  ->  Ta) 

T,  **♦  Ta  «  (T,  Ta)  n  (T,  -*♦  Ta) 

A  function  is  said  to  be  (a  surjection)  onto  Ta  if  its  range  is  the  whole  of  Ta.  The 
arrow-symbols  used  to  denote  the  surjective  functions  are  derived  from  the  usual  function 
arrows  by  adding  an  extra  “head*.  The  most  important  are  those  used  to  denote  the 

partial  surjections,  the  total  surjections,  and  the  one-one  functions,  namely: 

IT,.  Tal 

T,  -*•  Ta  *  {  f :  T,-+*Ta  I  ran  f  =  Ta  ) 

T,  -*  Ta  tt  (T,  -**  Ta)  n  (T,  -*  Ta) 

T,  >-*  Ta  •  (T,  -**  Ta)  n  (T,  >-*  Ta) 

2S2  Noution  for  Function  Applications 

If  F  is  a  function  from  T,  to  T„  and  if  x  is  a  member  of  the  domain  of  F,  then  the  term 

F  x  denotes  the  unique  element  y  of  Ta  which  sUnds  in  the  relation  F  to  x.  in  other 

words  the  value  of  F  at  x.  The  simplest  way  to  formalise  this  is: 

IT,.  T,1 

F:T,-+*Ta:  x:T,  I  x*doa  F  *-  (x  ♦  F  x)  «  F 

In  fact  we  may  not  deduce  anything  interesting  about  the  term  F  x  if  F  doesn’t  denote  a 
function  or  if  x  is  not  in  the  domain  of  F.  (see  Appendix  2  for  further  details) 


§2.4  Simple  Operators 


2.4.1  Difference,  union,  and  intersection  functions. 


IT) 


* 
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2.4.2  Subset  and  proper  subset  relations. 


[  T 1 


2.43  Natural  Numbers 

The  natural  numbers  have  an  element,  0.  There  is  an  injective  total  function,  succ,  on  the 
natural  numbers,  whose  range  does  not  contain  0. 


0:  N 

succ:  W  >-»  N 


0  4  ran  succ 


Notation 

N,  a  N  -  (0) 
pred  A  succ'1 

Theorems: 

Recursion  Principle 
IT! 

x:T:  g:T— »T  *-  3,  f:N— »T  .  f  0  ■  x  a  succi£  *  £  ig 
Induction  Principle 

S:P  N  ►  0«S  a  (r  n:S  .  succ  n  «  S)  -*  S=N 


Note: 

This  theorem  is  the  justification  for  our  using  the  "recursion  equation"  form  of 
specification  for  the  iterative  composition  function  iter  defined  in  §2.7. 


2.4.4  Numerals 

The  Arabic  digits  denote  numbers  defined  by 

1  A  sue  0,  2  A  sue  1,  ...  9  a  sue  8 

The  usual  conventions  concerning  the  numbers  denoted  by  multi-digit  sequences  apply. 


2.4.5  Arithmetic  Operators  and  Relations 


Notes; 

The  operator  symbols  *  and  -  are  given  additional  meanings  here.  In  any  context  the 
particular  meaning  of  one  of  these  symbols  can  be  determined  from  the  types  of  its  operands. 

Addition  is  defined  as  the  repealed  taking  of  successors. 

11 1  Multiplication  is  defined  by  repealed  addition. 

“ '  Notice  that  the  subtraction  operator  is  partial,  since  no  Natural  number  precedes  0. 

1,1  Repetition  is  denoted  by  R"  and  explained  in  §2.7. 

R*  is  a  relation  formed  by  taking  the  union  of  all  repetitions  of  the  relation  R,  as 
explained  in  §2.7. 

1,1  The  term  (_.♦■)  denotes  a  function  which  adds  ■  to  its  argument  More  generally,  the 
following  conditional  syntactic  equivalences  bold: 


f  : 

T, 

x  Ta 

Tj  : 

a:T,; 

t:T, 

(e  £.  _) 

a  X 

tsT,  . 

.  f(8. 

t) 

f  : 

T, 

*  T, 

-*  T,  ; 

t:T, 

(_  L  t) 

a  X 

b:T,  . 

£  (  B  , 

t) 

2.4.6  Segments  of  the  natural  numbers 


2.4.7  Finite  Sets  and  their  Cardinality 

A  finite  set  of  elements  of  T  is  a  subset  of  T  which  can  be  put  into  a  one-one  correspondence 
with  some  initial  segment  of  the  natural  numbers. 


* 


£ 


§2.3  Operators  on  Relations 

In  this  section  we  define  relational  composition,  relational  restrictions,  relational  overriding  and 
relational  image.  Since  functions  are  simply  specialised  kinds  of  relation,  the  relational 
operators  defined  below  may  also  be  applied  to  them. 


(T,,Tt,T,l 

I 

Z3J  Composition 

$  - 

*'  _  I  _  s  (T,«-*Ta)  *  (Ta«-»Ta)  -»  (T,*-*Ta) 


H  V  R, : T,*-*Ta;  Ra:Ta«->Ta:  x:T,i  z:Ta  . 

'S  (x.z)  €  £R,  l  R,)  •*  3  y:Ta  .  (x,y)«R,  *  (y,*)«Ra 


c> 


Some  authors  also  use  the  sign  •  defined  by:  Rj  •  R,  *  R,  i  R, 


fci 


152  Domain  and  Range  Restriction 


I 

/: 

X  ' 

?. 


It  is  often  convenient,  particularly  when  performing  algebraic  manipulations,  to  place  domain 
restrictions  to  the  left  of  the  relation;  we  therefore  define  the  following  variants  of  the  domain 
restriction  operators: 


.V 

.V 

V 


153  Relational  Overriding 


7? 
*  * 


- , 

_  •  _  s  (T,»-»Ta)  X  (T,*-T,)  —  (T,*-*!*) 


V  R,,  Ra:T,«-»Ta  . 

R,  •  Ra  =  (R,  \  ( don  Ra))  U  Ra 


ii 


2-5.4  Generalised  Application:  Relational  Image 

The  image  of  a  set  S  through  a  relation  R  (sometimes  called  the  R-image  of  S)  is  the  set  of 
elements  of  the  range  of  R  to  which  R  maps  elements  of  S. 


- , 

_  (  _  It  (T,  «-»  Ta)  *  (P  T.)  -»  (P  Ta) 


V  R:T,«-»Ta;  S:P  T,  . 

R  (  S  J  *  (  y: Ta  |  (3  x:S  .  xRy)  ) 


Syntactic  Equivalence: 

R:T,<-»Ta;  t:T,  R(  t  )  *  R(  it)  ) 

Theorems: 

CT.T,.Ta,Ta.T4l 


R:T,«-»Ta:  S,:P  T,;  Sa:  P  Ta 

h- 

R  (  dom  R  J  s  ran  R 

R: T,«-*Ta:  St:P  Tti  Sa:  P  Ta 

h- 

R'*  (  ran  R  )  >  dom  R 

R:  T,«-*Ta;  S, ,  Sa:  Ta 

►— 

RC  S,  U  S,  )  *  R(S,J  U  R(Sj] 

R:T,«“*Ta;  S,,Sa:  Ta 

>- 

RC  s,  n  Sa  )  C  R[S,)  f>  R(Sa) 

F : T,>+*Ta:  S,.Sa:Ta 

►— 

Fl  s,  n  sa  )  s  FISJ  n  F[Sa) 

R:T,<-*Ttj  StlSa:T, 

H- 

S,  C  Sa  -•  R(S, J  c  R(Sa) 

R:  T,«-*Ta 

►— 

id ( dom  R)  c  R  I  R“ 

R:T,^Ta 

>— 

idlran  R)  C  R'*  1  R 

R:  T,«-*Ta 

b- 

R‘*  «  Ta  -*♦  T,  -*  id  (dom  R) 

FJ  T,**+Ta 

►— 

id (ran  F)  =  F*  »  F 

R,:T, R,:Ta*-»T, 

h- 

(R,  J  Rar*  3  R,  •  ,  R,  * 

Rt:  T,«-»Ta;  R,: Ta«-*Ta 

h- 

don(R,  |  R,)  >  R,-‘l  dom  Ra  ; 

R,:T,«^Ta!  RjsT,*-*!, 

¥- 

ran(R,  |  Ra>  3  R,[  ran  R,  ) 

R(:  X,«-*T,s  R,:  Ta«-*Ta;  Ra 
R:T,*-*Ta 

RfRj:Ti*^Ta!  R3:1a<->Ta 

Ri  •  Ra- T,^*Ta;  Ra:  Ta«-*Ta 
Ri.Ra;T. F:Ta>*»Ta 


'a«-*T«»-  R,  l  (R,  »  I 
*-  R  I  (id  Ta> 

*-  (R,  U  Ra)  » 

*-  (R,  n  R,)  » 

*-  (R,  n  R,)  I 


>j)  *  1 R*  I  Ra)  l  Ra 
«  R  3  (id  Tt)  l  R 

Ra  *  (R,lRa)  U  (RjiRj) 
Ra  C  (R,|R,)  n  (Ra|Ra) 
F  *  (R.IF)  fl  (RalF) 


R^Rj.-T.^T,;  Ra:  Ta<_*Ta 
Ri :  T,*-*Ta:  Ra.  Ra:  Ta*-+Ta 


*-  R,  =  Ra  -•  (R, >Ra)  c  (RaiRa) 

i-  R,  £  Ra  — *  (R,lRa)  C  (R,lRa) 


R,:  T,«-*Ta;  Ra,  Ra:Ta<-*Ta 
R,:T,«-*Ta:  Ra.  Ra:  Ta<-*Ta 
F :  T,-**Ta:  Ra,  Ra:  Ta*-»Ta 


R,  J  (R,  U  R,)  s  ( R,  jRj)  U  (R,  jRa) 
R,  »  (Ra  n  R,)  c  (R, iRa)  n  (R, |Ra) 
F  I  (Ra  n  Ra)  -  (FIR,)  D  ( F »Rj) 


Ri » Ra=  T|wTa 

R,«  Ra: 

R,.Ra:T,~Ta 

R,,Ra:T,*-*Ta 


•-  (R,  U  Ra) ''  =  R,”  U  R,-‘ 

-  (R,  n  R,)-*  «  R,-'  n  R,’* 

*-  (R,  -  Ra) *'  *  R,"  -  Ra-' 

•-  R,  :  R,  «■*  R,'1  c  Ra'' 


Ri  •  Ra.  Ra:  T  ,*-*Ta 
R:T,~Ta 
R,.Rj:T,-»Ta 
Ri  ( Ra**  T  ,*-*7  a 


•-  R,  •  (Ra  •  R,)  =  (R,  •  R, )  •  R, 

-  (R  •  ())  =  R  *  (O  •  R) 

>-  dom(R,  •  Ra)  =  don  R,  <J  dom  Ra 
*-  ran(R,  •  Ra)  =  R,(T,  -  don  RaJ  U  ran  Ra 


$ 


§2.6  Finite  Sequences 

2.6J  Given  4  set  T,  the  finite  sequences  of  T  ere  the  finite  partial  functions  from  N  to  T  whose 
domains  are  initial  segments  of  the  natural  numbers. 


i 


m 


__  aeq  T  - 

I  1  f:  W  •#»  T  I  do»  f  »!..«£  1 

__  nq,  T  - 

I  aeq  T  -  i  ()  ) _ 


For  example: 


{  1>— *5,  2'~>6,  3*— *77  )  €  aeq  N 

,/  {  21- *prim«e  )  «  aeq  (P  K) 

In  general  the  following  syntactic  sugar  is  used  for  extensional  specifications  of  sequences: 


S3 

<> 

e 

(> 

<*t> 

a 

{  1*— *a,  ) 

<*,  . 

•  •  ».>  • 

< 

<: 

Theorem: 

A- 

a:  aeq 

T,i  £:T,-*Ta 

-to 


*-  elf  «  aeq  T, 


i 


2.62.  Sequence  Construction  Operators 

One  way  of  building  a  new  sequence  is  to  push  a  new  element  onto  the  front  of  an  existing 
sequence,  thus 


I 


I 

conas  CT  x  (aeq  T ) )  — *  aeq  T 


V  t:Ts  a: aeq  T  . 

t  cona  a  =  (  !•— *t  )  U  (succ‘'ja) 


v 


«» 


V- 


Another  way  is  to  push  the  new  element  onto  the  end  of  the  sequence,  thus 

i 

snoc:  ((aeq  T >  x  T >  — ►  aeqlT) 


V  t:T;  a: aeq  T  . 

t  anoc  a  =  a  U  (  8ucc  #s  • >  x  ) 


Syntactic  Equivalence: 

t,  *’  t,  s  t,  gona 

t,  *'  t,  s  t,  snoc  t, 
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Theorems 

L  Primitive  Recursion  for  Sequences 
IT,.  T,1 

x:  Ta;  g:T,  *  Ta  -*  Ta 

>- 

3,  f:  (aeq  T,)— *Ta  . 
f  <>  »  x 

V  t=T,;  s:s»q  T,  .  f(t  cons  •)  *  g(t,  f  ■) 

2.  Sequence  Induction 

IT] 

S:P(saq  T)  (<>«S)  a  (Vs:S;  t:T  .  (t  conn  s)«S)  —*  S~(saq  T) 
2.6J  Sequence  Selection  Operators 


hd,  first,  last: 

ssq,  T  -* 

i 

T 

tl,  back. 

front: 

ssq,  T  -♦ 

ssq  T 

first  * 

X  s: saq 

T 

1  a*<>  . 

(s  1) 

front  * 

X  a-’ aeq 

T 

1  s a<>  . 

af  ( 1 . .  (prad  Ms) ) 

back  * 

X  «: ssq 

T 

1  ■*<>  . 

succis  \  (0) 

last  • 

X  s: saq 

T 

1  m*<>  . 

si  Ns) 

hd  * 

first 

tl 

back 

2.6.4  Sequence  Operators  —  Append,  Reverse 


Notes: 

The  term  (_  -  as,)  denotes  an  N  ■+*  W  function  which  maps  a  number  n  into  the 
number  n-Ne,.  See  note  of  §2.4.5. 

Syntactic  Equivalence: 

s,,  b3:  aeq  X  — ^  e,  *  a}  a  a,  »  e3 

Theorems: 

a:eeq  T  >-<>»s  =  s»<>ra 

e,,8j,e,  Beq  T  >-  a,  •  (a,  •  s,)  =  <6,  •  a,)  «  a, 

a, .  a,:  aeq  T;  t:T  ►-  it  cons  a,)  •  a,  =  t  cona  (a,  •  a,) 


8,,Bj:a«q  T 
e:  aeq  T;  t:T 

t:T 


2.63  Subsequences 


*-  rev(  s,  •  83  )  =  (rev  sa)  •  (rev  9,) 
rev(  t  cons  e  )  =  (rev  ■)  anoc  t 
*-  rev  <>  *  <> 

*-  rev  <t>  5  <t> 

*-  rev  1  rev  =  id(seq  T) 


Theorems: 


9:  eeq  T:  n:  N  (9  for  n)  e  (9  after  n)  »  9 
9:  aeq  T  t-  (a  for  la)  :  a 

a:  aeq  T  *-  (9  after  0)  «  a 

2j6£  Sequences  of  Relations 

Distributed  composition  and  override  of  sequences  of  homogeneous  functions  are  defined  by 
primitive  recursion  over  sequences. 


[  T  J 


1 

_  • 

- , 

a 

aeq  (T«-»T) 

-*  ( T«-*T ) 

• 

<>  ■  id  T 

1 

<>  *  id  T 

v 

a:  a#q(T*-»X) ; 

R:T«-+T  . 

a(R  cona  a) 

■  R  a  (as) 

|(R  cona  a) 

-  R  1  (as) 

Theorems: 


9,.  aa:  eeq(T«-*T)  |(e,  •  a,)  =  (ib,)  i  (la,) 
a,,  a,:  eeq(T+-»T)  ►*  a<a,  «  a,)  ■  (aa,)  9  (99,) 


§2.7  Iteration  and  Transitive  Closure 

The  nth  iterate  of  a  homogeneous  relation  is  its  n-fold  composition  with  itself.  This  definition 
is  justified  by  the  Recursion  Principle  for  natural  numbers  (see  §2.43) 


Syntactic  Equivalence: 

R‘  *  t  iter  R 

The  (reflexive)  transitive  closure  of  a  homogeneous  relation  is  the  union  of  all  its  iterates,  its 
irreflexive  transitive  closure  is  the  union  of  all  its  iterates  but  the  zeroth. 


Theorems: 


R:  i 

a.nsN 

►- 

(R“)“  «  (R*)*  *  R'»  ■  •' 

R:  (T«-»T)  5 

■  >  n:  N 

»- 

(R*l  1  ( R")  -  R'»  •  •» 

R:  (T«-*T); 

n:N 

►— 

CRT*  =  <R'*)* 

R,.Ra:T«-*T 

i  n:N 

►- 

(R,lRa)  =  (Ra»Rt)  -»  (R,  ,  R,)-  =  R,"  »  R,* 

R:  (T«->T) 

R*  1  R  =  R* 

R:  (T«-*T) 

►— 

R*  1  R  -  R*  .  R  »  R» 

R:  (T*-*T) 

<  R* ) *  =  R* 

R:  (T«-*T) 

(R*)M  »  ( R ** ) * 

R:  (T«-*T) 

K- 

( R*)  '*  *  (R  ‘)* 

R,.R,:T«-»T 

»- 

(R,»R,1  =  (RalR,)  -*  (R,  |  Ra)*  s  R,‘  j  R,‘ 

R,.Ra:T«-*T 

h- 

R,*  U  Ra*  C  (R,  U  Rj)# 

h- 

8UCC*  a 

BUCC*  = 
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Appendix  1 
The  Z  Type  System 


(omitted  in  Draft) 


Appendix  2 

Rules  of  Reasoning  for  Z 
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Abstract 

One  of  che  more  prominent  features  of  the  Z  specification  technique  is  its  use  of 
acheaaa.  This  document  gives  a  compact  description  of  what  schemas  are  and 
how  they  are  manipulated.  Some  of  the  notations  introduced  are  still  considered 
preliminary. 
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1.  Introduction 

Schamas  are  a  device  for  organising  the  presentation  of  the  mathematical  text  of  Z 
specifications.  Specifications  in  Z  are  generally  given  as  predicates  relating  observations  of  the 
object  specified;  for  example,  the  following  specification  is  satisfied  by  any  right-angled  triangle: 

Let  the  positive  real  numbers  a,  b,  and  c  be  the  lengths  of  the 
given  triangle’s  three  sides.  Then 

aa  *  ba  =  c2 

In  this  specification,  it  is  the  English  text  which  associates  the  names  a,  b,  and  c  with  the  sides 
of  triangles.  In  Z,  the  mathematical  text  would  in  addition  introduce  the  variable’s  types 
(suppose  ft’  is  the  set  of  positive  real  numbers): 

a,  b,  c:  R* 

This  pattern  of  declaration  and  predicate  occurs  so  frequently  in  Z  specifications  - 

in  sets  <a,b,c:  R’  I  aa  +■  ba  =  cal 

in  functions  Xa.b.c:  R*  I  aJ  ♦  ba  *  c*  .  */,  ab 

in  predicates  Va.b.c:  R*  1  aa  *  ba  *  c*  .  c>a  *  c>b 

3a.b,c:  R*  I  aa  ♦  ba  =  ca  .  a  *  b 

that  it  has  taken  on  a  life  of  its  own;  it  has  become  the  ocheaa: 


Pythagorean _ 

I  a,  b.  c:  R’ 


♦  ba  a  C2 


The  above  is  a  named  schema  (Pythagorean)  expressing  the  relationship  holding  among  the  sides 
of  a  right-angled  triangle. 

The  advantage  of  recognising  and  naming  schemas  is  that  it  simplifies  the  presentation  of  large 
but  shallow  mathematical  text  (which  is  typical  of  specification). 


-  •  ■  *-  *->  ■ 
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2.  Definition,  notation,  and  naming  of  schemas 


2.1.  Definition  of  a  schema 

A  schema  comprises  a  signature  part  and  a  predicate  part,  either  of  which  may  be  empty.  The 
signature  part  is  a  list  of  variable  declarations,  and  each  declaration  consists  of  the  variable’s 
name  and  its  type.  For  example,  the  following  signature  declares  two  variables: 

chief:  PERSON 

Indiana:  P  PERSON 

chief  is  of  type  PERSON  (that  is,  it  may  take  values  from  that  set),  and  indiana  is  of  type 
P  PERSON  (the  powerset  of  the  set  PERSON).  The  set  PERSON  itself  is  assumed  to  be  defined 
elsewhere. 

The  predicate  part  of  a  schema  consists  of  a  single  predicate  -  for  example: 
chief  *  indiana 

The  type  constructors  (P  etc.)  and  the  predicate  syntax  are  given  in  Part  1  of  the  Z  handbook. 


2.2.  How  schemas  are  written 

Schemas  may  be  written  in  either  a  horizontal  or  vertical  form: 

Horizontal 

chief:  PERSON;  indiana:  P  PERSON  I  chief  4  indiana 

vertical 


- , 

chief:  PERSON;  indiana;  P  PERSON 


chief  4  indiana 


The  above  schema  describes  the  relationship  between  the  chief  of  an  indian  tribe  and  his  indiara. 
In  the  horizontal  form,  the  signature  and  predicate  are  separated  by  a  vertical  bar  (pronounced 
"such  that").  In  the  vertical  form,  the  signature  and  predicate  are  separated  by  a  horizontal  line 
(again  "such  that"),  and  the  schema  itself  is  enclosed  in  a  box.  As  a  convenience,  declarations 
may  be  broken  at  semicolons,  and  long  predicates  may  be  broken  at  conjunctions  (a),  and 
written  on  several  lines  with  the  ;  or  *  elided  -  for  example. 


chief ; 

1 

PERSON 

Indians 

P  INDIAN 

chief  * 

Indians 

Indians 

=  ( ' 

tv*.  V"*  i pc  yy  J>v*  ww  J-V  ww  W  -nr  jwv  *Jf  V'  W 1  *v’  ^.”  -.TV-.'  TTWWWWTnvwi 
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2.3.  How  schemas  are  named 


If; 

% 


£ 


t 


R 


I 


Naming  a  schema  introduces  a  syntactic  equivalence  between  the  name  and  the  schema  itself.  In 
the  horizontal  form,  a  schema  is  named  by  introducing  the  name  and  the  schema  together, 
separated  by  a  ("is  syntactically  equivalent  to’): 

Tribe  a  chief:  PERSON:  indians:  P  PERSON  !  chief  *  indians 

In  the  vertical  form,  the  schema  is  named  by  labelling  its  surrounding  box: 

Tribe _ _ _ _ _ 

chief:  PERSON 

indians:  P  PERSON 


chief  4  indians 


I 


a 


The  Schema  Language 


-6- 


i 


3.  Schemas  within  mathematical  text 

Section  1  above  noted  that  many  of  the  mathematical  notations  of  set  theory  have  a  schema-like 
syntax.  Set  comprehension  is  one  example;  here  is  the  set  of  all  tribes: 

(chief:  PERSON:  indians:  P  PERSON  | 

chief  *  indiana  .  (chief,  Indiana)). 


I 


h 


■v 


i 


i 


% 

<• 


Using  the  syntactic  equivalence  deTmed  in  section  22  above,  one  could  write  this  as  just 
(Tribe  .  (chief,  indiana)!. 

or.  using  the  convention  introduced  in  section  L 2  of  the  handbook,  as  simply  (Tribe).  This 
macro-like  use  of  schemas  was  in  fact  their  original  application,  and  the  "raw1*  mathematics 
could  always  be  recovered  by  substituting  a  schema's  body  wherever  its  name  occurred. 


3.1.  Rules  of  syntactic  equivalence 

Given  below  are  the  contexts  in  which  schemas  may  appear  directly  in  mathematical  text. 

Sec  comprehension 

A  schema  enclosed  in  set-braces  "O"  is  syntactically  equivalent  to  the  corresponding  set 
comprehension. 

(Tribe) 

is  equivalent  to 

(chief:  PERSON:  indians:  P  PERSON  |  chief  indians) 

In  some  circumstances,  the  brackets  can  be  omitted;  see  12  below.  When  we  use  this 
form  to  denote  a  set,  we  choose  not  to  know  the  ordering  of  components  in  elements 
of  the  set.  Hence  we  follow  the  practice  of  using  this  form  only  where  the  ordering 
does  not  matter.  We  disallow  sentences  like: 

(Tribs)  S  PERSON  *  (P  PERSON), 

(c.  s)  <  (Tribs)  where  c:  PERSON:  s:  P  PERSON. 

We  allow  sentences  like 

(Tribs  I  Sindians  <  120)  s  (Tribe). 

[Here,  #  is  the  cardinality  operator  on  sets]. 


.v 
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Lambda  abstraction 

A  schema  preceded  by  "X"  and  followed  by  is  syntactically  equivalent  to  the 
corresponding  lambda  abstraction. 

XTribe.  Sindian* 

is  equivalent  to 

Xchief:  PERSON;  indiana:  P  PERSON  |  chief  *  indiana.  Sindian*. 

The  projection  function  which  for  a  given  tribe  gives  the  set  of  its  indians  is 
XTriba.  indiana.. 

If  cr;  Triba,  then  the  application  of  this  projection  function  to  tr, 

(XTriba.  indiana )  ( tr ) , 

is  often  written  indiana(cr)  or  tr.  indiana  for  convenience. 

Quantification 

A  schema  preceded  by  "Y*  or  "3",  and  followed  by  is  syntactically  equivalent  to  the 
corresponding  quantification. 

3Trib*. indiana  a  O 

is  equivalent  to 

3chi#f:  PERSON;  indiana:  P  PERSON  I  chief  *  indiana.  indiana  *  O 

Tuple 

A  schema  preceded  by  the  symbol  "tuple”  is  syntactically  equivalent  to  the  ordered 
tuple  of  its  variable  names  in  some  undetermined  order.  For  example, 

tuple  Triba 

is  an  ordered  pair  containing  the  names  chief  and  indiana,  i.e.  it  might  be 
(chief,  indiana) 

In  some  circumstances,  the  tuple  can  be  omitted;  see  12  below.  As  we  choose  not  to 
know  the  ordering  of  components,  we  follow  the  practice  of  using  this  form  only 
where  the  ordering  does  not  matter.  Hence  we  disallow 

tuple  Tribe  e  PERSON  x  (P  PERSON). 

while  we  allow 

tuple  Tribe  «  (Tribe). 
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Furthermore,  we  use  tuple  only  where  the  context  agrees  with  the  signature  of  the 
schema. 

?red 

A  schema  preceded  by  the  symbol  "pr ad”  is  syntactically  equivalent  to  its  predicate 
part. 

pred  Tribe 
is  equivalent  to 

chief  *  indiana 

In  some  circumstances,  the  pred  can  be  omitted;  see  12  below.  To  avoid  ambiguity, 
pred  should  be  used  only  where  the  context  agrees  with  the  schema’s  signature. 

3.2.  Omission  of  o,  tuple,  and  pred 

The  set  braces  "()“  can  be  omitted  when  the  schema  appears  as  part  of  a  type;  set  comprehension 
is  For  example, 

size:  (Tribe)  — *  N 

may  be  abbreviated 

size:  Tribe  — ♦  N 

"tuple”  can  be  omitted  where  syntax  requires  a  term,  and  "pred”  where  syntax  requires  a 
predicate.  For  example, 

chief  *  indiana  —•  (chief,  indiana)  «  (Tribe) 

is  equivalent  to 

pred  Tribe  -•  tuple  Tribe  «  (Tribe) 

which  can  be  abbreviated  (but  inadvisedly) 

Tribe  — •  Tribe  s  (Tribe) 

Note,  however,  that  here,  the  braces  < )  cannot  be  dropped. 
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4.  Basic  schema  operations 

The  basic  operations  of  renaming,  decoration,  inclusion,  and  extension  allow  schemas  to  be 
constructed  directly  from  other  schemas.  (Some  of  these  operations  are  special  of  more 

general  operations  introduced  in  section  6.) 


4.1.  Renaming  variables 

Renaming  a  schema  variable  changes  its  name  in  the  signature  and  in  the  predicate  part  (where 
it  may  be  necessary  to  further  rename  bound  variables  in  order  to  avoid  clashes).  The  notation 
is 

schema  (newnaae/oldnamel 

For  example. 


Tribe  (PH/ chief  1  ( cabiner/indianel  a 


As  usual, 

(new, /old,]  Cnew,/old,]  _ 

may  be  written 

(new, /old, .  neva/old,  ...] 


4.2.  Schema  decoration 

Schema  decoration  is  a  special  case  of  variable  renaming:  decorating  a  schema  is  equivalent  to 
so  decorating  each  of  its  variables.  Typical  decorations  are  superscripts  and  subscripts;  for 
example: 


Tribe'  * 


For  a  decorated  schema,  it  is  guaranteed  that  the  ordering  of  components  obtained  with  tuple 
and  set  comprehension  agrees  with  that  obtained  for  the  original  schema.  This  allows  us  to  write 
for  example. 


tupie  Tribe' 


tuple  Tribe. 
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4.3.  Schema  inclusion 

A  (super-)schema  can  be  built  from  other  (sub-)schemas  by  including  the  sub-schemas  in  the 
signature  of  the  super-schema.  Each  sub-schema  adds  its  variables  to  the  super-signature,  and  the 
sub-predicates  are  conjoined  with  the  super-predicate.  Duplication  of  variable  names  is  allowed 
(and  in  fact  is  common)  as  long  as  the  duplicated  variables  agree  in  type.  For  example,  let 

Squaws  a  Indians,  squaws:  P  PERSON  I  squaws  S  indians 

Then  the  following  four  schemas  are  equivalent: 
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4.4. 


Schema  extension 


A  new  declaration  can  be  added  to  the  signature  part  of  a  schema  by  the  notation 


acheaa;  newdeclaration 


For  example. 


Tribeadulta  a  Tribe;  squawa:  P  PERSON 


is  equivalent  to 


Tribaadulta  _ 

chief:  PERSON 

Indiana:  P  PERSON 
squawa :  P  PERSON 


chief  *  indiana 


A  new  predicate  can  be  conjoined  to  the  predicate  part  of  a  schema  by  the  notation 
echaaa  I  newpredicace 


For  example. 


SaallTriba  e  Tribe  1  Indiana  *  O 


is  equivalent  to 


SaallTriba _ 

chief:  PERSON 

indiana:  P  PERSON 


chief  4  indiana 
indiana  ■  ( ) 


vTribe  |  indiana  =  U.  *  Indiana  *  0 


is  equivalent  to 

V chief :  PERSON:  indiana:  P  PERSON  I 

chief  *  indiana  *  indiana  =  ( > .  * indiana  s  0 
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5.  Conventions  for  using  the  basic  operations 

The  following  is  a  mathematical  description  of  the  event  of  electing  a  new  chief.  In  it,  the 
variables  chief  and  indians  represent  observations  before  that  event;  chief'  and  indians* 
represent  observations  after  it.  candidates  is  the  set  of  indians  from  which  a  new  chief  will  be 
drawn. 

As  a  first  step,  let  the  schema  ATribe  describe  ail  events  which  do  not  change  the  membership 
of  the  tribe: 


ATribe _ 

Tribe 

Tribe’ 


<  chief  > 

( chief ' > 

u  indians 

u  indians' 

ATribe 

chief,  chief* : 

PERSON 

indians. 

indians* : 

P  PERSON 

chisf  * 

indians 

chief'  0 

indians* 

(chief  ) 

u  indians 

* 

(chief* > 

u  indians* 

I 

* 


Then  the  schema  NevChief  is  the  definition  of  the  event  of  electing  a  new  chief: 

NewChief _ | 

ATribe 

candidates:  P  PERSON 


candidates  S  indians 
chief'  «  candidates 


'  V 


\a.Va.V.i. 


A  maL‘ k  h 
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The  above  is  equivalent  to 

MawCh  1  a-f 

chief,  chief:  PERSON 

indiana,  Indiana ' , 
candidates :  P  PERSON 


chief  *  indiana 
chief'  4  indiana* 

(chief  >  u  indiana  = 
( chief  *  >  U  indiana ' 

candidates  -  indiana 
chief'  «  candidates 


Although  the  two  forms  above  are  equivalent,  the  choice  in  the  former  of  appropriate 
(sub-)schemas,  and  their  names,  has  allowed  a  more  effective  presentation  *  as  a  result,  it  is 
clear  that  NewChief  describes  a  tribal  event  (ATribe)  which  depends  on  one  parameter 
(candidates). 
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6.  Logical  schema  operations 
Section  3.1  above  introduced  pred,  which  allows  expressions  such  as 
pred  A  a  prod  S 

for  schemas  A  and  3.  And  where  allowed  by  section  12,  the  prad  can  be  omitted,  so  that  the 
above  predicate  can  be  written  (remembering  that  A  and  3  are  schemas): 

A  a  a 

This  suggests  that  a,  for  example,  could  be  defined  as  a  schema  operator  directly;  that  is,  a  a  b 
would  be  a  schema,  in  the  appropriate  context.  But  because  of  the  possible  confusion  between 
schemas  and  predicates,  it  is  essential  that  such  a  definition  would  satisfy  (schema  a  on  the  left): 

prad  (A  a  B)  a  (prad  A)  a  (prad  3) 

In  fact  there  is  a  simple  definition  which  has  this  property.  The  logical  schema  operations  of 
a,  v,  — and  quantification,  are  introduced  below. 


6.1.  Binary  operations 

Binary  logical  operations  applied  to  schemas  form  their  result  by: 

L  merging  the  operands*  signatures  (duplicated  variables  are  identified  -  but  their 
types  must  agree),  and 

2.  joining  the  predicate  parts  with  the  logical  operator  itself. 

For  example. 

Tribe  A  Squaws  a 


chief : 

- ! 

PERSON 

indians, 

squawv: 

P  PERSON 

chief  4 

indians 

squawe  C 

indiana 

This  is  of  course  equivalent  also  to 


Tribe 

Squaws 
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And  given  the  definition 

NoChange _ 

I  iTribe 


chief*  =  chief 


then 


NewChief  v  NoChange  a 


- ! 

hTribe 

candidates:  P  PERSON 


(candidates  s  indians  * 
chief*  €  candidates) 

v  (chief*  =  chief) 


The  above  schema  coven  the  contingency  that  the  incumbent  might  remain. 


6.2.  Unary  operations 

A  unary  operator  applied  to  a  schema  is  applied  to  the  predicate  part  directly;  the  signature  is 
unaffected.  For  example. 


-Tribe  a 


chief:  PERSON 

indians:  P  PERSON 


-( chief  *  indians) 


63.  Quantifiers 

Both  universal  and  existential  quantification  can  be  applied  to  schemas.  The  quantified  variable 
must  occtir  in  the  signature  of  the  schema,  and  it  must  agree  with  its  type  in  the  quantificatioa 
The  resulting  schema  is  formed  by  removing  the  quantified  component  from  the  signature  and 
so  quantifying  it  in  the  predicate  part.  For  example, 

Vi.ndi.ans:  P  PERSON  I  indians  »  (>.  Tribe  a 


chief:  PERSON 


Vindians:  P  PERSON  I  indians  *  ().  chief  <  indians 
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3chi«£:  PERSON.  Tribe  a 


Indiana:  P  PERSON 


3chie£:  PERSON,  chief  *  indians 


6.4.  Predicates  as  schemas 

Just  as  a  schema  can  be  written  where  a  predicate  is  required  (with  pred  perhaps  implied),  a 
predicate  can  be  written  in  the  place  of  a  schema.  The  implied  signature  is  formed  by  declaring 
each  free  variable  of  the  predicate,  where  each  variable’s  type  is  in  agreement  with  the  current 
context.  Thus 


is  equivalent  to 


BigTribe  a  Tribe  A  indians  *  < ) 


BigTribs  a  Tribs  A  (indians:  P  PERSON  I  indians  *  ()) 


(the  context  is  supplied  by  the  schema  Tribs).  and  is  finally 


BirjTi-i  hm 

chief:  PERSON 

indians:  P  PERSON 

chief  *  indians 
indians  *  () 


For  a  further  example,  see  7.6  below. 


6J.  Conventions  for  using  logical  schema  operations. 

A  description  of  the  state  of  a  practical  system  will  often  involve  a  large  number  of 
components,  and  many  of  the  operations  will  leave  all  but  a  few  of  the  components  unchanged. 

For  example,  in  practice,  a  tribe  will  have  some  non-eligible  members: 

NonEligible _ 

children,  squaws:  P  PERSON 

children  n  squaws  =■  ( ) 


and  we  know  that  election  of  a  new  chief  will  not  affect  these  non-eligible  members,  so  the 
election  event  must  conform  to 
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■NonEligible _ 

ANonEligibie 

NonEligible  =  NonEligible' 

where 

ANonEligibie  a  NonEligible  A  NonEligible’ 

The  practical  tribe  is  described  by 

PTribe _ 

Tribe 

NonEligible 

disjoint  < Indians,  children,  squaws> 

where 

Cl.  XI 

I 

disjoint:  P  (I  -+*  P  X) 

S  «  disjoint 

Yi.  j:  do»  S.  S  i  n  S  j  >  () 

The  event  of  electing  a  new  chief  is  described  by 

ElectChief  a  APTribe  A  NewChief  A  eNonEligible, 
where 

APTribe  a  PTribe  *  PTribe' . 
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7.  Spccial-purposc  schema  operations 

This  section  describes  further  schema  operations  which  have  been  developed  from  time  to  time 
for  use  in  particular  specifications.  Some  of  these  operations  have  become  part  of  the  standard 
repertoire;  some  have  not.  It  is  part  of  the  Z  approach  to  specification  that  special  tools  can 
and  should  be  developed  if  necessary;  the  following  list  of  operations  is  intended  to  serve  as  an 
example  of  how  this  has  been  done  in  the  past. 


7.1.  Hiding 

The  notation 

s  che  ma  X  var  i  abl  • 

is  syntactically  equivalent  to  the  schema  (see  6J  abo^e) 

3 variable:  type.  schema 

where  the  type  of  variable  is  taken  from  the  signature  of  schema.  As  a  further  convenience, 
acheaa\variable,\ variable,  . . . 

can  be  written 

schema X  (variable,,  variable,  ...) 

Finally,  the  list  of  to-be-hidden  variables  variable,,  variable,  . . .  can  be  taken  directly 
from  the  signature  of  another  schema.  That  is, 

schema,  \  schema, 

is  equivalent  to 

schema,  \  (“all  the  variables  of  schema, 
which  are  alao  in  schema,’) 

(in  which  the  predicate  part  of  schema,  is  ignored). 
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7.2.  Projection 

Projection  hides  ail  variables  except  those  mentioned.  Thus  the  notation 
schema  r  (variable,,  variable,,  ...) 

hides  all  variables  of  schema  except  variable,,  variable,,  ....  And  similarly  to  hiding, 
schema,  f  schema, 

is  syntactically  equivalent  to  the  schema 

schema,  \  (“all  the  variables  of  schema, 
which'  are  not  in  schema,*) 

(Again  the  predicate  part  of  schema,  is  ignored).  Projection  of  schema,  onto  schema,  retains 
only  those  variables  also  in  the  signature  of  schema^  all  others  are  hidden. 


13.  Consistency 

The  notation 

schema,  ►  schema, 
or  schema,  4  schema, 

is  read  "schema,  consistent  with  schema,”;  it  is  syntactically  equivalent  to  the  schema 
(schema,  r  schema,)  — •  (schema,  f  schema,) 

And  the  notation 

schema,  schema, 
is  equivalent  to  the  schema 

(schema,  i  schema,)  *  (schema,  ►  schema,) 

An  example  of  consistent  with  is  given  in  section  S  below. 


7.4.  Forward  relational  composition 

The  notation 


A  I  3 

denotes  the  forward  relational  composition  of  the  two  schemas  A  and  3.  It  is  used  in 
specifications  where  A  and  3  describe  events,  and  follow  the  "undashed  before/  dashed  after" 
convention  (NewChief  in  section  3  above  is  such  a  schema).  The  composition  A>3  describes  the 
event  "a  followed  by  3". 


Assuming  for  illustration  the  definitions 
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a.  a' : 

S 

a.  a' :  S 

a!  :  Alpha 

b'5  :  Baca 

P(a,  a 

.  a'  ) 

Q(b.  a,  a'  ) 

(in  which  a!  is  an  output  from  event  A.  and  b?  is  an  input  to  event  3)  the  forward  relational 
composition  is  formed  as  follows: 

L  All  after  variables  of  A  which  match  before  variables  of  3  are  identified  by  renaming 
both  variables  of  each  matching  pair  to  a  single  fresh  variable  (variable'  in  A  matches 
variable  in  3): 


A1  a  A  CeVa'l  a 


a,  a8:  S 
a!  :  Alpha 


P(a,  a8,  a'  ) 


31  a  3  [a8/ a  1  a 


a8,  a* :  S 
b?  :  Beta 


Q(b.  a8,  a’) 


2.  The  renamed  schemas  are  conjoined,  and  the  fresh  variable(s)  hidden: 

A  ;  3  a  (A1  a  si)  \  a8  a 

- 1 

a.  a':  S 
a!  :  Alpha 
b?  :  Beta 


3a°:  S.  P(a.  a8,  a’)  a 
Q(b,  a8,  a’) 


The  notation 


C  »  0 

denotes  an  operation  performed  as  a  two-stage  pipeline:  an  operation  satisfying  specification  C  is 
performed  at  the  first  stage,  and  an  operation  satisfying  0  at  the  second  stage.  The  output  from 
the  first  stage  is  used  as  input  to  the  second  stage  if  required.  The  'pipe'  operator  >>  is  used  in 
specifications  where  C  and  D  describe  events  and  follow  the  convention  that  the  names  of  inputs 
and  outputs  end  in  and  1  respectively. 
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Assuming  for  illustration  the  deTmitions 


then 

C  »  D  a  (CCa/a! 1  a  DCa/a?l>  \  a. 

7.5.  Domain  and  range 

The  operations  do  a  and  ran  are  used  on  schemas  following  the  before/  after*  convention  as  in 
7.4  above.  Taking  A  and  3  as  before, 

doa  A  a  A  f  Cundashed  variables  of  A”)  a 


ran  is  formed  by  projecting  onto  the  dashed  variables,  and  then  undashing  them  (a  special  case 
of  renaming).  Thus 

(ran  3)'  a  B  r  ('dashed  components  of  B“) 

and  so 

ran  B  a 


Notice  that  the  variables  of  ran  B  are  undaahed,  and  that  this  renaming  has  forced  a  change  of 
bound  variable  (s  to  a9). 


-22- 
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7.6.  Application 

[f  schema  a  fallows  the  before/after'  convention,  and  schema  S  is  undashed,  then  the  application 
of  A  to  S  is  written 

A  tSj 

and  is  syntactically  equivalent  to  the  schema 
ran  (S’  I  A) 

(It  is  necessary  to  decorate  S  so  that  the  composition  operator  >  properly  identifies  its  now 
dashed  variables  with  the  undashed  variables  of  A.) 

This  operation  is  very  like  forming  the  image  of  a  set  through  a  relation.  For  example,  given 


<?  A _ _ _ _ 

- 1 

a:  N 

a,  a* :  N 

1  ana 

a  =  5 

a’  a  a  ♦  1 

then 


a  (SI  a 


- -l 

a:  N 


a  =  8 


Following  section  6.4  above,  this  could  be  written 


A  (a  =  51  a 


a:  N 


a  *  6 


i.\ 

i 


•\ 


7.7.  Overriding 

If  schemas  a  and  3  follow  the  before/after'  convention,  then  A  overridden  by  B  is  written 
A  •  B 

and  is  equivalent  to  the  schema 

(A  *  -doa  8)  v  8 

This  operator  is  very  like  the  overriding  of  functions  or  relations.  For  example,  given 


I 
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8.  Schemas  and  theorems 

Having  used  schemas  to  present  a  specification,  one  can  also  use  schemas  to  construct  hypotheses 
and  state  theorems  about  it.  If  a  schema  describes  the  static  properties  of  some  object,  one  may 
wish  to  ask  if  there  can  be  such  an  object.  For  example,  if  the  set  PERSON  is  non-empty, 
then  there  exist  an  individual  and  a  set  of  people  which  together  form  an  instance  of  the 
schema  Tribe: 


PERSON  *  (>  i-  3Tri.be 
which  is  syntactically  equivalent  to 
PERSON  ?e  ( >  •— 

3chie£:  PERSON;  indiana;  P  PERSON  |  chief  4  Indiana. 

Also,  we  may  wish  to  ask  if  the  objects  described  by  some  schema  have  certain  properties.  As  a 
first  example,  when  a  new  chief  is  elected,  the  new  chief  is  not  a  child.  This  can  be  formulated 

*-  vElectChief.  chief  4  children 

(ElectChief  is  defined  in  section  6J).  The  theorem  can  also  be  formulated 

ElectChief  chief  4  children 

which  is  syntactically  equivalent  to 

hPTribe  *  NewChief  *  «Non£ligible  *- 
chief  4  children. 

The  proof  is  based  on  the  axioms  for  the  three  schemas  on  the  left  hand  side: 


(1) 

chief  e  candidates 

from  NewChief 

(2) 

candidates  S  Indians 

from  NewChief 

(3) 

chief  4  indiana 

(1),  (2) 

(4) 

indiana  n  children  *  ( ) 

from  PTribe  in  hPTribe 

(5) 

chief  4  children 

(3),  (4). 

This  completes  the  proof. 


A  second  example  is  the  following:  given  a  non-empty  tribe,  it  is  always  possible  to  elect  a  new 
chief,  that  is. 


>-  VTribe  I  indian*  *  ().  3Tribe’.  NewChief. 


or  alternatively. 


Tribe  I  indiana  4  ( )  *-  3Triba' .  NewChief. 
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L  H>£  abstract  state 

The  abstract  state  consists  dm  ply  of  a  two-dimensional  array; 
ABS _ _ 

- l 

[array:  ROW  x  COL  -♦  VALUE 


where 

ROW  a  0. . (Rowe  -  l) 

COL  •  0. . (Cola  -  1) 

for  some  positive  integers  Rows  and  Colo. 


2 


r  a 

W-V, 

£ 


*> 


r, 

■r. 


r: 


■y 


2.  The  abstract  operations 

There  are  two  abstract  operations  -  one  for  reading  from  the  array,  and  one  for  writing  to  it 
(ReadA  for  read  abstract.  Writ* A  for  urite  abstract): 

.  AABS  a  ABS  a  ABS’ 


1  The  concrete  state 

The  concrete  state  consists  of  a  one-dimensional  vector;  it  is  just  large  enough  to  accomodate  all 
of  the  values  in  the  abstract  array: 


CELL  a  0.. (Celia  -  1)  where  Cells  =  Rows  •  Cola 

4.  The  abstraction 

The  abstraction  functions  lay  out  the  array  row-by-row  in  the  vector.  IN  and  OUT  are  inverses: 


Y.V.V.V  ^  V  V  V  r  r.  <v-;  v’  s'  V 


3 


i 


OUT. 


ABS‘ 

CON’ 


[Vr:  ROW;  c;  COL.  array*  (r.c)  ■  vector*  ((Cols  •  r)  ♦  c) 1 


t: 


% 


OUT  could  have  been  defined  as  follows,  with  the  same  effect: 
OUT  a  IN* 


5.  The  concrete  operations 

There  are  two  concrete  operations,  corresponding  to  the  two  abstract  operations: 


ACON  «  CON  a  CON* 


ReadC _ 

ACON 
r?;  ROW 
c?:  COL 
v!;  VALUE 


vector '  a  vector 

v!  *  vector! (Cola  *  r?)  ♦  c?) 


WriteC _ 

ACON 
r?:  ROW 
c?:  COL 
v?:  VALUE 


vector’  =  vector  •  [((Cols  #  r?>  ♦  c?)  v?l 


6.  Proof  of  refinement 

The  proof  of  refinement  is  in  two  parts.  The  first  part  proves  properties  of  the  abstraction 
itself,  independent  of  the  operations  that  are  being  refined  (subsections  6.1  and  6.2).  The  second 
part  proves  properties  of  the  abstract  and  concrete  operations,  in  their  corresponding  pairs  (6.3 
for  ReadA  and  ReadC,  6.4  for  Write  A  and  WriteC). 


% 

I 
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6.1  TN  is  total 

We  must  show  (VABS.  1 3C0N.  INI  1;  that  is  (we  expand  the  predicate),  we  must  show 
[V  array:  ROV  x  COL  -*  VALUE. 
t3  vector:  CELL  — »  VALUE. 

(Vr:  ROV:  c:  COL.  array  (r.c)  *  vector  ((Cols  »  r)  ♦  c) 11 ] 

We  do  this  by  constructing  the  required  vector  ((3  vector  ...1)  explicitly: 

(1)  [V  e:  CELL,  vector  (e)  »  array  (e  div  Cols,  e  aod  Cols)] 

But  to  show  that  this  vector  exists,  we  require 

(V  e:  Cell. 

e  dix  Cols  «  ROV 
*  e  mod  Cols  «  COL] 

We  need  this  because  array  is  defined  only  for  arguments  in  the  appropriate  sets  -  and  we  must 
show  that  the  arguments  are  in  the  appropriate  sets.  In  fact,  it  follows  from  from  the 
definitions  of  CELL,  ROV,  and  COL.  and  the  properties  of  div  and  mod. 

Now  we  know  there  is  a  vector  with  property  (I),  we  must  show  it’s  the  right  one.  For  this,  we 
need 

(V  array:  ROV  x  COL  -*  VALUE. 

[v  e:  CELL,  vector  (•)  =  array  (•  div  Cols,  •  nod  Cols)] 

— *  (Vr:  ROW;  c:  COL.  array  (r.c)  *  vsctor  ((Cols  *  r)  ♦  c)]J 
and  this  follows  from 

(Vr:  ROV;  c:  COL. 

(2)  (Cola  •  r)  ♦  c  €  CELL 

A  ((Cols  »  r)  ♦  c)  div  Cols  =  r 
A  ((Cols  •  r)  ♦  c)  mod  Cols  s  c) 
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We  must  show  [VCON’ .  13ABS’.  OUT]];  that  is,  we  must  show 
(V  vector  * :  CELL  -*  VALUE. 

(3  array:  ROV  x  COL  -»  VALUE. 

[Vr:  ROW:  c:  COL.  array'  (r,c)  =  vector’  ((Cols  *  r)  ♦  c))J] 

But  to  show  this,  we  need  only  that 

(vr:  ROW;  e:  COL.  (Cols  *  r)  ♦  c  €  CELL] 
and  this  has  already  been  shown  ((2)  above). 

6.3  ReadC  is  a  refinement  of  ReadA 

Showing  that  a  concrete  operation  is  a  refinement  of  an  abstract  operation  is  done  in  two  stages. 
In  one  stage,  we  must  show  that  whenever  the  abstract  operation  can  be  applied,  then  so  can  the 
concrete  one;  this  is  done  for  RsadA  and  RsadC  in  section  &2L  In  the  other  stage,  we  must  show 
that  anything  the  concrete  operation  does  is  acceptable  in  the  sense  that  the  abstract  operation 
could  have  done  it  also  (section  &12). 

6.11  Liveness  -  If  the  abstract  operation  can  be  applied,  then  so  can  the  concrete  one. 

We  must  show  that  (ReadA  *  IN)  — *  (3C0N*;  v!:  VALUE.  ReadC];  that  is,  we  must  show  that 
for 


array,  array’  : 

ROW  x  COL  -*  VALUE 

vector  : 

CELL  —  VALUE 

r°  : 

ROW 

o'5  : 

COL 

v 1  : 

VALUE 

the  following  holds: 

array'  =  array 
A  v  =  array  (r^.c?) 

A  (Vr:  ROV:  c:  COL.  array  (r.c)  =  vector  ((Cols  *  r)  ♦  c) 


(3  vector':  Cell  -*  VALUE:  v!:  VALUE, 
vector '  =  vector 

v!  =  vector  ((Cols  •  r1)  ♦  o'5)! 

This  implication  is  easy  to  prove,  because  the  consequent  is  aluays  true;  the  antecedent  is 
unnecessary  in  the  proof.  The  consequent  is  true  because  ReadC  can  always  be  applied,  and  this 
follows  from 


6 


(Cols  ■  r?>  ♦  c?  «  CELL 

which  we  hive  already  shown  ((2)  above,  with  change  or  variable). 


63.2  Safety  -  The  concrete  operation  does  only  what  the  abstract  operation  allows. 

We  must  show  that  (IN  A  ReadC  a  OUT  a  (3ABS';  vis  VALUE.  ReadAl)  — *  ReadA;  that  is,  we 
must  show  that  for 


array,  array'  :  ROW  *  COL  — *  VALUE 
vector,  vector' :  CELL  — *  VALUE 

r-5  :  ROV 

c?  :  COL 

v!  :  VALUE 

the  following  holds 

(Vr:  ROV;  c:  COL.  array  (r.c)  *  vector  ((Cola  *  r)  ♦  c)l 
a  vector'  =  vector 

a  v!  =  vector  ((Cola  •  r?)  ♦  c?)3 

a  (vr:  ROW;  c:  COL.  array'  (r,c)  =  vector’  ((Cola  »  r)  ♦  c)l 

a  (3  array':  ROV  x  COL  -*  VALUE:  v!:  VALUE. 

array'  =  array 
v!  =  array  (r?,c?)l 


array'  =  array 
a  v!  =  array  (r'>.c,l 


This  is  trivial. 

6.4  VriteC  is  a  refinement  of  VnteA 

6.4.1  Liveness  -  If  the  abstract  operation  can  be  applied,  then  so  can  the  concrete  one. 

We  must  show  that  (VriteA  a  in)  — »  OCQN*.  VriteCl;  that  is,  we  must  show  that  for 

array,  array' :  ROV  *  COL  —  VALUE 
vector  :  CELL  —  VALUE 

r'1  :  ROV 

c->  :  COL 

V»  :  VALUE 


the  following  holds 
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array’  *  array  •  ((r?,c?)  >->  v?l 
*  (Vr:  ROW;  c:  COL.  array  (r,c)  =  vector  ((Cols  *  r)  ♦  c) 


.  (3  vector':  Cell  -»  VALUE. 

vector’  »  vector  •  (((Cols  *  r?)  ♦  c?)  »-*  v?] 


As  usual,  this  is  guaranteed  by 

(Cols  •  r?)  ♦  c?  «  CELL 

6-* -2  Safety  -  The  concrete  operation  does  only  what  the  abstract  operation  allows. 

We  must  show  that  (IN  *  VriteC  a  0(JT  a  (3ABS’.  WriteAl)  -*  WriteA;  that  is,  we  must 
show  that  for 


array,  array’ 

:  ROW  x  COL  — »  VALUE 

vector,  vector’ 

1 :  CELL  -*•  VALUE 

r? 

:  ROW 

c? 

:  COL 

v? 

:  VALUE 

P 

/ 


the  following  holds 

(Vr:  ROW;  c:  COL.  array  (r.c)  =  vector  ((Cols  »  r)  *0)1 
a  vector’  =  vector  •  (((Cols  »  r?)  ♦  c?)  >-*  v?l 

a  (Vr:  ROW;  c:  COL.  array’  (r,c)  =  vector’  ((Cols  »  r)  ♦  c) ] 
a  (3  array’:  ROW  x  COL  — *  VALUE. 

array’  =  array  e  ((r',.c'’)  v?]J 


e 


array’  =  array  •  ((r^.c1)  >—  v’’] 
We  show  this  by  considering  two  cases: 

Case  1 

We  show  that 


2 


(Vr:  ROW;  c:  COL. 

(r.c)  *  tr'>,c'’)  -*  array’  (r.c)  =  array  (r,c)l 
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This  is  a  consequence  of 

[Vr:  ROV;  c:  COL. 

(r.c)  *  (r?,c?) 

— •  (Cols  •  r)  ♦  c  *  (Cols  »  r?)  ♦  c?l 
That  is,  it  is  a  consequence  of  the  non-overlapping  of  the  row-by-row  representation. 

Case  2 

We  show  that 

array  (r?.c?)  *  v? 

This  is  triviaL 

7.  Conclusion  -  what  was  important 

The  representation  of  two-dimensional  arrays  as  one-dimensional  vectors  is  hardly  a  startling 
refinement;  the  mathematics  above  is  a  lot  of  work  for  something  so  trivial!  Even  so,  the  exercise 
has  not  been  entirely  pointless.  We  discovered  by  doing  it  that  the  validity  of  this  particular 
refinement  depends  on  the  following  facts: 

The  mapping  function  (Cola  »  r)  ♦  c  is  guaranteed  to  return  a  result  in  the  set  CELL: 

(Vr:  ROV:  c:  COL.  (Cola  »  r)  ♦  c  s  CELL] 

it  is  an  injection: 

r’’:  ROV 
c~>\  COL 

(Vr:  ROV;  C:  COL. 

(r.c)  *  (r^.c0)  — *  (Cola  »  r)  ♦  c  *  (Col8  »  r?)  ♦  c?l 

and  it  is  onto  (that  is,  it  has  an  inverse  which  is  total): 

(Vr:  ROV;  c:  COL. 

((Cols  *  r)  ♦  c)  div  Cola  =  r 
*  ((Cols  »  r)  ♦  c)  mod  Cols  =  cl 

In  larger  examples,  it  might  be  harder  to  "guess’*  just  what  the  crucial  points  of  the  refinement 
are  -  that's  why  it  is  important  to  be  able  to  be  systematic  And  it  should  be  remembered  that 
such  proct  s  of  refinement  are  necessary  only  once  for  each  refinement.  Any  subsequent 
development  which  uses  the  refinement  does  so  for  free. 
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Abstract 


A  number  of  specification  examples  are  developed  in  a  notation  which  is  based  on  typed  set 
theory. 
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Specification  Examples 


A  Symbol  Table 


The  first  example  specifies  a  simple  symbol  table.  It  demonstrates  using  a  mathematical  function 
to  specify  an  abstract  data  type.  We  will  specify  a  symbol  table  with  operations  to  update, 
lookup  and  delete  entries  in  the  symbol  table.  We  will  describe  our  table  by  a  partial  function 
from  symbols  (SYfl)  to  values  (UAL): 


st  :  SYfl  -*♦  UAL 


The  arrow  -**  indicates  a  function  from  SYfl  to  UAL  that  is  not  necessarily  defined  for  all 
elements  of  SYrt  (hence  'partial').  The  subset  of  SYfl  for  which  it  is  defined  is  its  domain  of 
definition: 

dom( st ) 

If  a  symbol  s  is  in  the  domain  of  definition  of  st  (s  «  dom(st))  then  st(s)  is  the  unique 
value  associated  with  s  (stCsl  «  UAL).  The  notation  <  s  <-*  v  >  describes  a  function  which  is 
only  defined  for  that  particular  s 

dom(<  s  •— *  v  >)  =  <s> 

and  maps  that  s  onto  v 

<  S  ■— *  v  >(S)  =  v 

More  generally  we  can  use  the  notation: 

{  x,  —*  y , «  x,  — •  y, . x.  *-*  y.  > 

where  all  the  x,'s  are  distinct  to  define  a  function  whose  domain  is  <  x, ,  xa . x,  >  and 

whose  value  for  each  x,  is  the  corresponding  y,.  For  example,  if  we  let  our  symbols  be  names 
and  values  be  ages  we  have  the  following  mapping: 

st  =  <  “Fred"  •— *  23.  "ttary"  19  > 

which  maps  ‘Fred*  onto  23  and  "Mary'  onto  19,  then  the  domain  of  st  is  the  sec 
dom(st)  =  <  'Fred*,  'flary'  > 


and 


st ( "Fred* )  =  23 
St ( 'nary')  =  19 

The  notation  <>  is  used  to  denote  the  empty  function  whose  domain  of  definition  is  the  empty 
sec  Initially  the  symbol  table  will  be  empty: 

st  =  <> 
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We  are  describing  a  symbol  table  by  modelling  it  as  a  partial  function.  This  use  of  a  function 
is  quite  different  to  the  normal  use  of  functions  in  computing  where  an  algorithm  is  given  to 
compute  the  value  of  the  function  for  a  given  argument.  Here  we  use  it  to  describe  a  data 
structure.  There  may  be  many  possible  models  that  we  can  use  to  describe  the  same  object. 
Other  models  of  a  symbol  table  could  be  a  list  of  pairs  of  symbol  and  value,  or  a  binary  tree 
containing  a  symbol  and  value  in  each  node.  These  other  models  are  not  as  abstract  because 
many  different  lists  (or  trees)  can  represent  the  same  function.  We  would  like  two  symbol 
tables  to  be  equal  if  they  give  the  same  values  for  the  same  symbols.  However,  it  is  possible  to 
distinguish  between  two  unordered  list  representations  that  as  symbol  tables  are  equal;  on  the 
other  hand,  for  the  function  representation  different  functions  represent  different  symbol  tables. 
The  list  and  tree  models  of  a  symbol  table  tend  to  bias  an  implementor  working  from  the 
specification  towards  a  particular  implementation.  In  fact,  both  lists  and  trees  could  be  to 
implement  such  a  symbol  table.  However,  any  reasoning  we  wish  to  perform  involving  symbol 
tables  is  far  easier  using  the  partial  function  model  than  either  the  list  or  tree  model. 

As  some  operations  can  change  the  symbol  table  we  represent  the  effect  of  an  operation  by  the 
relationship  between  the  symbol  table  before  the  operation  and  the  symbol  table  after  the 
operation.  We  use: 

st.  st‘  :  SYO  UAL 

where  by  convention  we  use  the  undecorated  symbol  table  (st)  to  represent  the  swte  before  the 
operation  and  the  dashed  symbol  table  (st‘)  the  state  after.  The  operation  to  update  an  entry 
in  the  uble  is  described  by  the  following  schema: 


A  schema  consists  of  two  parts:  the  declarations  (above  the  centre  line)  in  which  variables  to  be 
used  in  the  schema  are  declared,  and  a  predicate  (below  the  centre  line)  containing  predicates 
giving  properties  of  and  relating  those  variables.  In  the  schema  Update  the  second  line  declares 
a  variable  with  name  "s9"  which  is  the  symbol  to  be  updated.  The  third  line  declares  a 
variable  with  name  ’v9"  to  be  the  value  to  be  associated  with  s9  in  the  symbol  table.  By 
convention  names  in  the  declarations  ending  in  '7"  are  inputs  and  names  ending  in  *!*  will  be 
outputs;  the  "7"  and  "!"  are  otherwise  just  part  of  the  name. 

The  predicate  part  of  the  schema  states  that  it  updates  the  symbol  table  (st)  to  give  a  new 
symbol  table  (st‘)  in  which  the  symbol  s7  is  associated  with  the  value  v7.  Any  previous  value 
associated  with  s7  (if  there  was  one)  is  lost. 
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The  operator  •  (function  overriding)  combines  two  functions  of  the  same  type  to  give  a  new 
function.  The  new  function  f  •91s  defined  at  x  if  either  f  or  9  are  defined  at  x,  and  will 
have  value  g(x)  if  9  is  defined  at  x.  otherwise  it  will  have  value  f(x): 

dom(f  Og)  *  dom(f)  u  dom(g) 

x  6  domtg)  (f  •  g)(x)  =  g(x) 

x  it  dom(9)  A  x  e  dom(f)  — »  (f  •  gHx)  3  f(x) 

For  example: 

<  "Hary*  •-*  19,  -Fred"  •-*  23  >  •  <  "Fred"  •-*  25.  "George"  •-»  S2  > 

3  <  "nary"  •-*  19.  "Fred"  *-*  25.  "George"  •-»  52  > 

For  the  operation  Update  above  the  value  of  st‘(x)  is  v7  if  x  3  s7,  otherwise  it  is  st(x) 
provided  x  is  in  the  domain  of  st.  In  our  example  we  are  only  using  •  to  override  one  value 
in  our  symbol  uble  function;  the  operator  •  is,  however,  more  general:  its  arguments  may  both 
be  any  functions  of  the  same  type. 

The  following  schema  describes  the  operation  to  look  up  an  identifier  in  the  symbol  table: 


The  second  line  of  the  signature  declares  a  variable  with  name  "s7"  which  is  the  symbol  to  be 
looked  up.  The  third  line -of  the  signature  declares  a  variable  with  name  "v!"  which  is  the 
value  that  is  associated  with  s7  in  the  symbol  table. 

The  first  line  of  the  predicate  states  that  the  identifier  being  looked  up  should  be  in  the  symbol 
table  before  the  operation  is  pc.  rmed;  the  above  schema  does  not  define  the  effect  of  looking 
up  an  identifier  which  is  not  in  ihe  table.  The  second  line  states  that  the  output  value  is  the 
value  associated  with  s7  in  the  symbol  table  st.  The  final  line  states  that  the  contents  of  the 
symbol  table  is  not  changed  by  a  LooUUp  operation. 
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The  operation  to  delete  an  entry  in  the  symbol  table  is  given  by. 


Delate. 


St.  St*  :  SYH 
S 9  :  SYfl 


s’7  6  dom(st)  a 
st‘  =  st  \  <  s9  > 


To  delete  the  entry  for  s'7  from  the  symbol  table  it  must  be  in  the  uble  to  start  with 
(s'*  «  don(stl).  The  resultant  symbol  table  st*  is  tha  symbol  table  st  with  s9  deleted  from 
its  domain.  We  use  the  domain  subtraction  operator  \  where: 

dom(f\s)  3  dom(f)  -  s 

x  *  dom(f\sl  -•  Cf\s)Cx)  3  f(x) 

where  f  is  a  function  and  s  is  a  set  of  elements  of  the  same  type  as  the  domain  of  f.  For 
example: 

<  -nary*  19.  "Fred*  2S.  "Geor3«"  *-*  6Z  >  \  <  "flary",  "Fred"  > 

»  <  "Georse"  —•  6Z  > 


Exercise  1:  Specify  an  operation  to  Find  all  (the  set  of)  identifiers  that  have  a  given  value,  v9,  in 
the  symbol  uble.  □ 
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File  Update 


The  second  example  is  a  specification  of  a  simple  file  update.  It  uses  sets  and  functions  to 
model  the  file  update  operatioa 

Each  record  in  the  file  is  indexed  by  a  particular  key.  We  will  model  the  file  as  a  partial 
function  from  keys  to  records: 

f  :  Key  -*•  Record 

A  transaction  may  either  delete  an  existing  record  or  provide  a  new  record  which  either  replaces 
an  existing  record  or  is  added  to  the  file.  The  transactions  for  an  update  of  a  file  will  be 
specified  as  a  set  of  keys  d7  which  are  to  be  deleted  from  the  file,  and  a  partial  function  u7 
giving  the  keys  to  be  updated  and  their  corresponding  new  records.  We  add  the  further 
restriction  that  we  cannot  both  delete  a  record  with  a  given  key  and  provide  a  new  record  for 
that  key.  For  example,  if: 

f  *  <  k,  •—*  r,»  k,  •—»  r j,  kj  •—*  r,»  k4  *— *  r4  > 

d?  *  <  k,,  k4  > 

u7  *  <  k,.  •  r|(  k,  ►—»  r,  > 

then  the  resultant  file  f‘  will  be: 

f*  *  {  k,  r,#  i<3  r  U9  r3  y 

Our  specification  is: 


File  Update. 


f , 

r 

:  Key 

-*♦  Record 

d7 

: 

IP  Key 

u7 

• 

Key  -*♦ 

Record 

d7 

e 

don*(  f ) 

A 

d7 

n 

domtu7) 

=>  <>  a 

r 

3 

(f\d7) 

•  u7 

The  original  file  f  and  the  updated  Hie  f  are  modelled  by  partial  functions  from  keys  to 
records.  The  keys  to  be  deleted  (d7)  are  a  subset  of  Key.  Hence  d7  is  an  element  of  the 
powerset  of  Key  (the  set  of  all  subsets  of  Key);  the  notation  IP  Key  is  used  to  denote  the 
powerset  of  Key.  The  updates  u7  are  specified  as  a  partial  function  from  Key  to  Record. 
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We  can  only  delete  records  already  in  the  file  f.  Hence  the  set  of  keys  to  be  deleted  d7  must 
be  a  subset  of  the  domain  of  the  original  file  { d 7  c  dom(f)).  We  are  precluded  from  trying  to 
both  delete  a  key  and  add  a  new  record  for  the  same  key  as  the  intersection  of  the  deletions 
with  the  domain  of  the  updates  must  be  empty  (d7  n  dom(u7)  =  <>).  The  resultant  file  f*  is 
the  original  file  f  with  all  records  corresponding  to  keys  in  d7  deleted  (f\d7),  overridden  by 
the  new  records  u7. 

The  last  line  of  File  Update  could  have  equivalently  been  written: 
f*  =  (f  •  u7)  \  d7 

Although  it  is  not  always  the  case  that  these  two  lines  are  equivalent,  the  extra  condition  that 
the  intersection  of  d7  and  domtu7)  is  empty  ensures  their  equivalence  in  this  case. 

Lemma:  Given  d?  n  domCu7)  -  <>  the  following  identity  holds: 

If  •  u7)  \  d7  *  (f  \  d7)  •  u7 

Proof:  Firstly  we  show  the  domains  of  the  two  sides  are  equal: 

dom( ( fan7) \d7J  3  domffeu7!  -  d7 

3  tdom(f)  U  domtu7))  “  d7 
3  (domtn  -  d7)  u  (dom(u7)  -  d7) 

3  (dom(f)  -  d7)  U  domCu7) 

as  d7  n  do«(u7)  3  <> 

3  do»(f\d7)  u  domlu7) 

3  dom( ( f \d7)*u7) 

Secondly,  for  any  key  b  in  tha  domain,  the  two  sides  are  equal.  We  prove  this  for  the  two  cases: 
b  «  dom(u7)  and  b  t  dom(u7): 


as  domCu7)  n  d7  3  O 
as  b  *  domCu7)  a  b  t  d7 
as  b  «  do»(u7) 

as  u*  assumed  b  «  domC ( f«u7) Vd7) 
as  b  i  domCu?) 

as  b  i  dom(u7) 

as  b  «  dom( (f«u7l\d7l  □ 

In  the  specification  of  File  Update  if  we  were  not  given  the  extra  restriction  then,  as  specified 
in  the  last  line,  updated  records  would  have  precedence  over  deletions.  If  the  alternative 
specification  were  used  then  deletions  would  have  precedence  over  updates.  It  is  sensible  to 
include  the  extra  restriction  in  the  specification  as  it  allows  the  most  freedom  in  implementation 
without  any  real  loss  of  generality. 

Exercise  2:  In  the  version  of  File  Update  given  above  each  key  has  (at  most)  a  single  record 
associated  with  it.  Define  a  new  data  type  for  a  file  that  allows  multiple  records  for  a  single 
key,  and  a  new  file  update  operation;  the  inputs  to  the  operation  will  have  to  take  a  different 
form  from  those  given  above.  (Hint  Use  relations.)  Q 


Ca)  If  b  e  dom(u7)  then 
b  i  d7 

( ( f%j7) \d7l (b )  =  u7(b  ) 
and  C(f\d7)«u7)(b)  3  u7(b ) 

(b)  If  b  t  dom(u7)  then 

((f«u7’\d7)(k)  3  (f«u7)(b) 
3  f(b) 

and  ((f\d7)«u7)(b)  3  ( f \d7) (b ) 

3  f(b) 
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Virtual  Memory 


Virtual  memory  can  provide  a  much  larger  apparent  memory  to  the  user  than  the  physical  main 
memory  available.  A  virtual  memory  (vn)  is  implemented  by  a  combination  of  main  memory 
(nri)  which  stores  part  of  the  current  virtual  memory,  a  memory  map  (nnap)  which  maps  those 
virtual  addresses  currently  resident  in  the  main  memory  into  the  corresponding  main  memory 
address,  and  secondary  memory  (Sn)  which  stores  that  part  of  the  virtual  memory  that  cannot 
fit  into  main  memory. 

If  we  let  Virtual_Addr  be  the  set  of  virtual  memory  addresses,  Ham_Addr  be  the  set  of  main 
memory  addresses,  and  nu  be  the  set  of  values  that  can  be  stored  in  a  unit  of  memory,  then  we 
can  model  a  virtual  memory  system  by: 


Virtualjlemory 


vn 

Virtual _^ddr  — *  DU 

nn 

na  i  n  _flddr  — *  mj 

sn 

Virtualjlddr  -**  fill 

nnap  : 

Virtual_flddr  >**  nain_Addr 

r  an ( nnap  J  *  na i n  _flddr  a 

vn  » 

sn  •  enn  •  nnap) 

Both  vn  and  nn  are  total  functions  they  are  defined  for  all  values  in  their  respective  sources, 
Virtual_Addr  and  f1ain_flddr.  SM  is  not  necessarily  defined  for  all  values  in  its  source  and 
hence  is  a  partial  function.  The  uncrossed  arrow  (— *)  is  used  to  indicate  a  total  function  and 
the  crossed  arrow  (-*♦)  to  indicate  a  partial  function. 

nriap  is  a  partial  function  that  is  also  a  one-to-one  correspondence:  for  each  element  in  its  range 
there  is  a  unique  corresponding  element  in  its  domain: 

V  y  :  r  an  ( Hflap  i 

V  x,«  x,  :  do Kt (nriap)  . 

CnHapCx,)  *  y  a  nnap (x, 5  *  y)  ^  (x,  =  x,) 

We  use  the  notation  for  a  total  one-to-one  correspondence  and  the  notation  ">♦*"  for  a 

partial  one-to-one  correspondence.  The  term  "injection’*  is  commonly  used  in  mathematics  for  a 
one-to-one  correspondence. 

The  first  predicate  in  the  schema  Virtual  Jlemory  states  that  the  range  of  nnap  is  the  whole  of 
Ha i n _Addr .  This  means  that  for  every  main  memory  address  there  is  a  corresponding  virtual 
memory  address;  such  corresponding  virtual  memory  addresses  are  unique  because  flflap  is 
one-to-one.  The  memory  map  is  only  defined  for  those  virtual  addresses  currently  corresponding 
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to  main  memory  addresses.  In  mathematics  a  function 

f  :  X  Y 

whose  range  is  equal  to  the  whole  of  its  destination  (Y)  is  called  a  'surjection**.  We  say  f  maps 
X  onto  Y. 

In  order  to  understand  the  second  predicate  in  Virtualjlemory  we  need  the  definition  of 
relational  (and  hence  functional)  composition  If  we  have  two  relations: 

f  :  X  «-*  Y 

9  :  Y  «-*  2 

then  we  can  compose  these  two  relations  to  give  a  relation 
9«f  :  X  •“*  2 
defined  by 

x  (9»f)  y  *  3y:Y  .  x  f  y  a  y  g  z 
The  domain  of  g*f  is  given  by 

do»(g«f)  *  <  x  :  dom(f)  I  3 y  :  do»(g)  .  x  f  y  > 

which  is  not  necessarily  the  whole  of  dom(f). 

Properties:  ran(f)  c  dom(9)  dom(g*f)  *  dom(f)  Ca) 

ran(h)  c  dam(g)  (f*g)»h*g»h  (b) 

Another  way  of  writing  composition  is  to  use  the  forward  relational  composition  operator  '  l" 
where 

fig  *  g  •  f 

The  second  predicate  of  Virtualjlemory  is: 

vn  »  sn  •  cnn  •  nnap) 

The  virtual  memory  is  equal  to  the  secondary  memory  except  where  virtual  addresses  are  in  the 
domain  of  the  memory  map,  in  which  case  the  contents  of  the  virtual  memory  locations  are 
given  by  the  contents  of  the  corresponding  (according  to  rtflap)  main  memory  locations.  For  an 
address  addr  the  contents  of  the  virtual  memory  is  given  by: 

Vn(addr)  =  SD(addr)  if  add  r  t  dom(  n(1«nriap  ) 

*  nm nnapi addr n  if  addr  «  doi»(nn»nriap) 

Note  that  the  specification  does  not  require  that  domCSfl)  and  dom(nn«nriap)  are  disjoint.  If  an 
address  is  in  both  domains  then  when  the  virtual  memory  is  used  the  contents  of  SH  are  ignored. 

31  AUg  84 
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Lemma:  domUirNflflap)  1  dom(firiap) 


Proof: 

domcnm  =  (1am_flddr  *  ranCHflap) 

as  nn  is  total  and  Hflap  is  onto. 
dom(nn«nnap)  =  dom(firiap) 

by  property  (a)  above  Q 

In  order  to  state  a  simple  theorem  about  Virtual Jlemory  we  need  to  introduce  the  concepts  of 
the  inverse  of  a  relation  (or  function)  and  the  identity  function  on  a  set.  The  inverse  of  a 
relation  R  is  the  relation  R‘l  defined  by: 

y  R"‘  x  if  and  only  if  x  R  y 

For  a  function  f  (a  function  is  a  relation  with  the  additional  constraint  that  for  any  x  in  its 
domain  there  is  a  unique  y  related  to  it  by  f)  its  inverse  f'1  is  not  necessarily  a  function.  For 
example,  if 

f  a  <  a  ' •  1»  b  w  1  ) 


then 

f'*  »  <  1  •-*  a.  1  >— *  b  > 

which  is  not  a  function  as  1  does  not  map  to  a  unique  value. 

The  identity  function  on  a  set  S  is  given  by: 

id(Sl  a  <  a  :  S  .  a  •— *  *  > 

It  maps  every  element  of  S  onto  itself. 

Properties:  We  have  the  following  useful  properties  of  inverses  and  identity  functions.  If 
R  ;  X  «-*  Y 

f  :  X  >♦*  Y 

(that  is,  R  is  a  relation  and  f  is  a  one-to-one  correspondence)  then: 


Cr" 

1  >  -*  a  r 

Cc) 

f* 

•  f  a  idldomlf ) ) 

(d) 

r  • 

id(dom(r ) )  =  r 

(e)  Q 

Exercise  3:  Prove  the  properties  (a)  -  (e)  given  above  Q 
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Theorem: 


nn  =  vn  »  nnap'1 


Proof : 


vn  =  sn  •  (nn  •  nnap) 

vn  «  nnap-'  =  (Sn  •  tnn  ®  nnapn  •  nnap” 

=  nn  •  nnap  •  nnap-‘ 

by  property  (b) 

as  ran ( nnap'1)  *  dom(nnap)  3  domtnn  o  nnap)  by  lemma 

3  nn  •  idCdomtnnap'M ) 

as  nnap  is  one  to  one  and  property  (d) 

=  nn 

as  domCnnap'1)  3  ran(nnap)  =  nam_Addr  3  dom(nn) 
and  property  (e)  Q 


Exercise  4:  Show  that: 


dooi(Sn)  u  do  HI  (nnap)  =  dom(Vn)  □ 


Exercise  3:  If  the  memory  units  in  the  description  given  are  pages  of  4K  bytes  give  a 
definition  of  nu  and  operations  to  read  and  write  single  bytes  in  the  virtual  memory  given  a 
byte  address.  (Ignore  nn,  Sn.  and  nn  for  this  exercise.)  □ 
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The  third  example  specifies  sorting  a  sequence  into  non-decreasing  order;  it  uses  bags  (multi-sets) 
and  sequences. 

The  input  and  the  output  to  Sort  are  sequences  of  items  of  some  base  type  X.  We  model  a 
sequence  as  a  partial  function  from  the  positive  natural  numbers  (IN*)  to  the  base  type  X  as 
follows: 


seq  X  a  <  s  :  IN*  -**  X  |  dom(s)  =  l..«s  > 

where  as  is  the  number  of  entries  in  the  mapping  s  (which  is  also  the  length  of  the  ^quenre 
s).  The  notation  of  enclosing  a  list  of  items  in  angle  brackets  can  be  used  to  construct  a 
sequence  consisting  of  the  list  of  items.  For  example: 

t  =  <  a.  b.  c  > 

■  {  l  a*  2  ►-*  b»  3  •—*  c  > 

We  can  select  an  item  in  a  sequence  by  indexing  the  sequence  with  the  position  of  the  item: 
t (21  *  b 

s  a  <s(l).  s(2).  ...  ,  s ( *s ) > 

The  empty  sequence  is  denoted  by  <>. 

The  output  of  Sort  must  be  in  non-decreasing  order.  »We  define: 


Non-Oecreasmg(s  :  seq  X) _ 

I 

Vi.j  :  dom(s)  .  i  <  j  -(s(jl  <  s(il) 


where  >  is  a  total  ordering  on  the  base  type  X. 

The  output  of  Sort  must  contain  the  same  values  as  the  input,  with  the  same  frequency.  We 
can  state  this  property  using  bags.  A  bag  is  similar  to  a  set  except  that  multiple  occurrences  of 
an  element  in  a  bag  are  significant.  We  can  model  a  bag  as  a  partial  function  from  the  base 
type  X  of  the  bag  to  the  positive  integers  where  for  each  element  in  the  bag  the  value  of  the 
function  is  the  number  of  times  that  element  occurs  in  the  bag: 

bag  X  a  X  -*♦  IN* 
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We  use  the  notation  (  .  .  .  1  to  construct  a  bag.  For  example: 

(  1.  2.  2.  2  1  =  <  1  —  1.  2  -*  3  > 

The  following  gives  some  examples  of  how  sets,  bags,  and  sequences  (in  this  case,  of  natural 
numbers)  are  related: 

<1.Z,Z.2>  =  <1 ,2.2>  =  <Z.1.2>  =  <1.2>  =  <2.1> 

Cl, Z. 2. 21  *  Cl, 2. 21  =  C2,l,21  X  Cl> 21  =  C2.ll  • 

<1 ,2.2.2>  *  <1.2.2>  /  <2, 1 ,2>  *  <l-2>  *  <2.1> 

In  specifying  Sort  we  would  like  to  say  that  the  bag  formed  from  all  the  items  in  the  output 

sequence  is  the  same  as  the  bag  of  items  in  the  input  sequence.  We  introduce  the  function 
items  which  forms  the  bag  of  all  the  elements  in  a  sequence.  For  example: 

items(<>)  *  (1 

items(<l>)  *  Cll 

i temsC <1 ,2.2> )  ■  i temsC <2, 1 ,2> 1  »  Cl. 2, 21 

i terns ( <1 ,2.3> 1  *  i temsC <2. 1 ,3> 1  =  Cl. 2, 31 

More  precisely: 


Each  element  of  the  base  type  X  is  mapped  onto  its  frequency  of  occurrence  in  the  sequence: 
The  function  items  is  more  concisely  given  by  the  equation: 


items(s)  *  ■  •  s'1 
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Finally,  the  specification  of  sorting  is  given  by: 
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Sort  is  an  example  of  a  non-algorithmic  specification.  It  specifies  what  Sort  should  achieve  but 
not  how  to  go  about  achieving  it.  The  advantage  of  a  non-algorithmic  specification  is  that  its 
meaning  may  be  more  obvious  than  one  which  contains  the  extra  detail  necessary  to  be 
algorithmic  The  specification  is  given  in  terms  of  the  (defining)  properties  of  the  problem 
without  biasing  the  implementor  towards  a  particular  form  of  algorithm.  There  are  many 
possible  sorting  algorithms.  The  implementor  should  be  allowed  the  freedom  to  choose  the  most 
appropriate 

Exercise  &  Rewrite  the  sort  specification  for  the  case  of  sorting  a  sequence  with  no  duplicates 
into  strictly  ascending  order.  0 
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Abstract 


The  following  message  system  is  based  on  the  message  handling  in  QCS.  The  specification  itself 
is  an  interesting  example:  it  combines  states  (of  input  and  output  devices),  and  gives  a  number 
of  examples  of  the  use  of  the  ">>"  operator  on  schemas. 


A  Message  System 


Message  Output 


We  can  represent  a  set  of  output  devices  by  a  mapping  from  a  device  name  to  a  sequence  of 
messages  that  have  been  output  to  that  device: 


nog  :  Name  -*♦  seg  Message 


The  operations  on  output  that  we  will  discuss  here  neither  create  nor  destroy  devices: 


ANQUT  3  NQUT  a  NQUT'  |  dam  nog’  =  dam  nog 


Sending  a  message  to  a  device  simply  appends  the  message  to  the  queue  for  that  device 


NSend. 


ANGUT 

n~>  :  Name 

m?  s  Message 


nog'  =  nog  •  C  n?  ■— *  nog(n?)»<m7>  } 
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A  Message  System  3 

Multiple  Destinations 


A  message  may  be  sent  to  a  set  of  destinations: 


NSendf1a 


ANOUT 

ns7  1 P  Nama 

m7  :  nessasa 

ns7  C  dom  noq  a 

noq’  3  noq  •  <  n  :  ns7 

n  >— *  noq(n)»<m?>  > 

All  the  names  in  ns7  must  correspond  to  valid  output  devices.  Each  device  in  n7  is  sent  the 
message. 

Conjecture 

Given: 

ToSat  a  n7  :  Name:  as'.  ■-  V  Name  l  ns!  *  <  n?  > 
the  fallowing  equality  holds: 

NSand0  ■  ToSet  >>  NSendf!, 

The  schema  operator  ">>"  identifies  the  outputs  (variables  ending  in  " ! ")  of  its  left  operand 
with  the  inputs  (variables  ending  in  *7")  of  its  right  operand;  these  variables  are  hidoen  in  the 
result.  All  other  components  are  combined  together  as  per  schema  conjunction  (a). 
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A  Message  System 


Message  Input 


We  can  represent  a  set  of  input  devices  by  a  mapping  from  a  device  name  to  a  sequence  of 
messages  yet  to  be  input  from  that  device: 


NIN _ _ 

i 

mq  :  Name  -**  seq  Hessage 


The  operations  on  input  described  here  will  neither  create  nor  destroy  devices: 

AN  IN  a  NIN  a  NIN’  |  dom  mq'  ■  dam  niq 

Receiving  a  message  from  a  device  simply  removes  it  from  the  head  of  the  input  queue  for  that 
device: 


NRece i ve0 


ANIN 

n'7  : 

Name 

m!  : 

Message 

m !  » 

hd(n iqtn7) )  a 

n  t  q' 

*  niq  9  <  n’7  •-*  tl(niq(n7))  > 

Send  and  Receive 


We  can  define  an  operation  that  both  sends  a  message  to  a  device  and  receives  a  message  from 
that  device: 


NSendRece t vea  a  NSenda  a  NRece tvea 


Con  iecture 


NSendRece i ve.  =  NSenda  !  NRece tvea 
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Combining  Input  and  Output 


We  will  introduce  NOEU  to  describe  the  combined  input  and  output  state  for  all  the  devices.  If  a 
device  can  be  used  for  input  then  it  must  be  able  to  be  used  for  output: 


An  input  operation  will  preserve  the  output  state  and  an  output  operation  will  preserve  the 
input  state: 


SNIN 

a 

ANOEV  I  NQUT' 

=  NOUT 

SNOUT 

a 

ANDEV  I  NIN' 

*  NIN 

where  ANOEU 

a 

NOEU  ^  noeu1 

The  operations  on  the  combined  state  are 


NSend 

2 

NSand0  a 

5NIN 

NSendfl 

2 

NSendfl,  a 

=NIN 

NRece i v« 

2 

NRece i vt,  a 

SNOUT 

NSendRece  t v« 

2 

NSendRece i ve„  a 

ANDEV 

Conjecture 

NSendRece i v« 

3 

NSend  ;  NRece i ve 
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Logical  Names 


Rather  than  work  wrh  actual  (physical)  device  names,  as  we  have  up  until  this  point,  we  would 
like  to  work  with  logical  names  that  are  mapped  into  physical  device  names.  We  use  the 
following  mapping  from  logical  names  to  physical  names: 


It  op  :  LName  -**  Name 


None  of  the  operations  discussed  here  modify  the  mapping  from  logical  names  to  physical 
names  hence  we  will  use: 


=LtoP  a  LtoP  a  LtoP'  !  LtoP’  =  LtoP 


If  a  logical  name  actually  corresponds  to  a  device  we  perform  the  operation  on  that  device, 
otherwise  we  use  the  device  with  physical  name  console: 


HapName. 


3LtoP 

dev  :  Name  -+*  seq  Message 

In7  :  LName 
n !  :  Name 


n!  »  C  In7  «  dom( 1 top  ;dev }  — »  ItopCln7). 

console 


The  operations  on  a  single  device  become 


LSend 


a  HapNametnoq/dev J  >>  NSend 


LReceive  a  MapNameCn iq/devl  >>  NRecaive 


LSendRecetve  a  HapNametn tq/dev 1  >>  NSendReceive 


Conjecture 


NOEV  |  dom  niq  *  dom  noq  h  LSendReceive  =  LSend  f  LReceive 
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Multiple  Logical  Destinations 


To  send  a  message  to  a  set  of  logical  names  we  need  to  map  the  set  of  logical  names  into 
physical  names.  If  none  of  the  logical  names  correspond  to  a  device  we  send  the  message  to  the 
device  with  physical  name  console: 


HapSet _ 

SLtoP 

Ins7  :  IP  Name 
ns!  :  IP  Name 
NQUI 


ns  I  *  ( 

I 


(ltop(lns7|  o  dam  noq  3  <>)  — »  <  console  >» 

ltop(lns7)  0  dam  noq 


The  operation  to  send  a  message  to  a  set  of  logical  devices  is: 

iSendfl  a  HapSet  >>  NSendfl 

Con  iecture 
Given: 

ToSetL  a  In7  :  LName;  Ins!  :  IP  LName  I  Ins!  =  <  In7  > 
the  following  equality  holds: 


LSend  3  ToSetL  >>  LSendH 
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Domains  of  the  Operations 


In  practice  we  would  like  all  the  operations  to  be  total  (denned  for  all  inputs).  Unfortunately 
the  operations  as  defined  are  not  total  If  a  name  (or  a  set  of  names)  does  not  correspond  to 
an  actual  device  then  the  name  will  be  translated  to  the  special  device  console;  if  the  console 
does  not  exist  the  operation  is  not  defined.  For  the  output  operations  ensuring  that  the 
console  exists  is  a  sufficient  pre-condition  for  the  operation  to  be  defined.  (We  will  also  need 
this  pre-condition  for  input.) 

Pre  a  NQEV;  LtoP;  m7  :  ttessa9e  !  console  «  dom  niq 
Remember  that  dom  mq  ;  dom  noq  so  console  *  dom  noq. 

Conjectures 


Pre;  In7  :  LName  h  dom  LSend 

Pre;  Ins7  :  IP  LNaiwa  b  dom  LSendH 

For  the  input  operations  we  need  the  additional  requirement  that  the  queue  of  messages  yet  to 
be  input  on  the  device  is  not  empty: 

Prein  a  Pre;  n7  :  Name  |  niqln7)  f  <> 

Con  iccturcs 

naoNameln iq/devl  »  Prein  h  dom  LReceive 
HapNameCn iq/devl  »  Prein  dom  LSendReceive 
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Specification 


Temporary  storage  provides  facilities  for  storage  of  information  in  named  "queues".  The 
operations  that  can  be  performed  on  an  individual  queue  are  either  the  standard  queue-like 
operations  (append  to  the  end  and  remove  from  the  beginning),  or  array-like  random 
read  and  write  operations. 


A  Single  Queue 


An  element  of  a  queue  is  a  sequence  of  bytt 


TSEIem  *  s«q(8ytel 


A  single  queue  may  be  defined  by: 


a r  :  seq( TSEIem 1 
p  :  IN 


p  S  »ar 


*rtay  ar  contains  the  items  in  the  queue.  The  size  of  the  array  is  always  equal  to  the 
number  of  append  operations  that  have  been  performed  on  the  queue  since  its  creation  - 
independently  of  the  number  of  other  (remove,  read,  or  write)  operations.  The  pointer  p  keeps 
track  of  the  position  of  the  item  which  was  last  removed  or  read  from  the  queue. 
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The  initial  state  of  a  queue  is  given  by  an  empty  array  and  a  zero  pointer. 

TSO_Initial  a  TSQ  I  (ar  3  <>)  a  (p  =  0) 

We  will  define  four  operations  on  a  single  TSQ.  The  definitions  of  these  operations  will  use  the 
schema: 

A  TSQ  a  TSQ  A  TSQ’ 

ATSQ  (A  for  change)  defines  a  before  state  TSQ,  with  components  ar  and  p  (satisfying  P  s  »ar), 
and  an  after  state  TSQ',  with  components  ar'  and  p'  (satisfying  p'  $  <*ar').  The  schemas  for 
the  operations  follow. 


Append,, 

!  ATSQ 


The  new  element  from7  (a  *7"  at  the  end  of  a  name  indicates  an  input)  is  appended  to  the  end 
of  ar  to  give  the  new  value  of  the  array.  The  position  of  the  new  item  is  returned  in  item:  (a 
* '  *  at  the  end  of  a  name  indicates  an  output).  The  pointer  position  is  unchanged. 


The  pointer  must  not  have  already  reached  the  end  of  the  array.  The  pointer  is  incremented  to 
the  next  item  in  the  queue  and  the  value  of  that  item  is  returned  in  into!.  The  contents  of  the 
array  is  unchaneed. 


The  position  item7  must  lie  within  the  bounds  of  the  current  array.  The  item  at  that  position 
in  ar  is  overridden  by  the  value  of  from7  to  give  the  new  value  of  the  array.  The  pointer 
position  is  unchanged. 
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so 

em 

to 


i  tem7  s  l  •  •  “a r 
into !  3  ar C i tern?) 
p'  =  i tern7 
ar '  3  ar 


The  value  of  the  item  at  position  item'’,  which  must  lie  within  the  bounds  of  the  array,  is 
returned  in  into!-  The  pointer  position  is  updated  to  be  item'7.  The  array  is  unchanged. 

In  the  above,  all  the  operations  have  been  specified  in  terms  of  the  array  ar  and  pointer  p. 
While  this  is  reasonable  for  the  Read  and  Unte  operations  it  does  not  show  the  queue-tike 
nature  of  the  Append  and  Remove  operations.  Let  us  now  show  that  the  queue-like  operations 
are  the  familiar  ones.  We  can  define  a  standard  queue  by: 


seqCTSElem] 


The  standard  append  to  the  end  of  a  queue  operation  is  given  by: 

Standard_Append _ ( 

AO 

from7  :  TSElem 


1  *  q  *  <fram?> 


where  AQ  a  Q  a  q\ 

The  standard  remove  from  the  front  of  the  queue  operation  is  given  by: 
Standard  Remove 

II 

AQ 

into!  :  TSElem 


q  *  < i nto ! >  * 


The  predicate  in  the  above  specification  may  be  unconventional  to  some  readers.  It  states  that 
the  value  of  the  queue  before  the  operation  is  equal  to  the  value  returned  in  into!  catenated 
with  the  value  of  the  queue  after  the  operation  This  form  of  specification  more  closely  reflects 
the  symmetry  between  Standard_Append  and  Standard_Remove  than  the  more  conventional: 

q’  3  tail(q) 
into  !  3  headCq) 
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To  see  the  relationship  between  standard  queues  and  temporary  storage  queues  we  need  to 
formulate  the  correspondence  between  the  respective  states: 

OL  i  k  e _ _ _ _ _ 

Q 

TSO 


q  »  t  a  1 1 '  ( ar  ) 


a 


,v 

.V' 


A  standard  q  corresponds  to  the  array  ar  with  the  first  p  elements  removed.  Given  this 
relationship  between  states  we  will  now  show  the  relationship  between  Append,,  and 
Standard  .Append.  What  we  will  show  is  that  if  we  perform  an  Append,  with  initial  state  TSQ 
and  final  state  TSQ1  then  the  corresponding  standard  queue  states  Q  and  Q*  (as  determined  by 
QLike  and  QLike'  respectively)  are  related  by  Standard.Append.  This  can  be  formalised  by  the 
following  theorem: 


Append,  A  QLike  A  QLike’  ►  Standard .Append 


Proof: 

1.  q.q’  :  seql TSEleml ;  from?  :  TSElem 
2-  q'  =  tai  1*' (ar '  ) 

3.  =  tail*(ar  •  <from7>) 

4.  =  (tail'(ar)l  *  <from7> 

5.  =  q  *  <from7> 

S.  Standard.Append 


from  QLike.  QLike'  and  Append, 

from  QLike' 

from  Append, 

as  p  Z  ear  from  TSQ 

from  QLike 

from  (1).  (5)  □ 


i 


We  can  now  do  the  same  for  Remove.  Again  we  would  like  to  show: 
Remove,  A  QLike  A  QLike'  H  Standard.Remove 


> 

Proof: 

1. 

q.q'  :  seql TSElem]; 

into!  :  TSElem 

from 

QLike.  QLike'  and  Remove 

2. 

p  <  »ar 

from 

Remove, 

ft 

3. 

q  3  tai  1*  (ar ) 

from 

QLike 

R 

4. 

»  <ar(p-*l)>  •  (tai 

1**'  (ar)) 

from 

(2)  and  property  of  tail 

5. 

=>  <  i  nto  !  >  •  (tail* 

tar’)) 

from 

Remove, 

f 

« *  • 

S. 

*  < i nto ! >  *  q' 

from 

QLike' 

\  •  V 

* 

7. 

Standard.Remove 

from 

(1).  (S)  Q 

ft 


o 


Errors 


a 


In  allowing  for  errors  we  can  introduce  a  report  to  indicate  success  or  failure  of  an  operation. 
If  an  error  occurs  we  would  like  the  TSQ  to  remain  unchanged.  This  can  be  encapsulated  by: 

ERROR _ , 

ATSO 

report!  :  CONOITIQN 


TSQ'  =  TSQ 


% 

V 

fe 
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In  the  operations  described  above  there  are  three  errors  that  can  occur  trying  to  remove  an  item 
from  a  "SQ  that  is  empty,  trying  to  read  or  write  at  a  position  outside  the  array,  and  running 
out  of  space  to  store  an  item. 


If  the  operations  work  correctly  the  report  will  indicate  Success: 


The  operations  given  previously  can  now  be  combined  with  the  erroneous  situations.  We  will 
redefine  the  operations  in  terms  of  their  previous  defini lions. 

Append  a  Append,,  a  Successful  v  NoSpace! 

Remove  a  Remove,,  a  Successful  v  NoneLeft! 

Urite  a  Urite,  a  Successful  v  QutofBounds!  v  NoSpace! 

Read  a  Read0  a  Successful  v  QutofBounds! 

Note  that  NoSpace!  does  not  specify  under  what  conditions  it  occurs.  The  specifications  of 
Append  and  Ur  i  te  do  not  allow  us  to  determine  whether  or  not  the  operation  will  be  successful 
from  the  initial  state  and  inputs  to  an  operation.  This  is  an  example  of  a  non-determ inistic 
specification.  It  is  left  to  the  implementor  to  determine  when  a  NoSpace!  report  will  be 
returned  (we  hope  it  will  not  be  on  every  call). 
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Named  Queues 


We  now  want  to  specify  a  system  with  more  than  one  queue.  A  particular  TSQ  can  be  specified 
by  name  and  the  above  operations  performed  on  it.  We  will  use  a  mapping  ts  from  queue 
names  (TSQName)  to  queues.  The  state  of  our  system  of  queues  is  given  by: 


ts  :  TSQName  -**  TSQ 


The  initial  state  of  the  system  of  queues  is  given  by  an  empty  mapping: 

TS.In.tial  a  TS  I  ts  *  O 

Our  operations  require  updating  of  a  particular  named  TSQ.  We  can  introduce  a  schema  to 
encapsulate  the  common  part  of  updating  for  operations  on  queues  that  already  exist: 

Updat  eQ _ _ 

hTS 

queue'7  :  TSQName 
hTSQ 


queue"7  e  dam(ts) 

TSQ  =  tstqueue"7) 

ts"  =  ts  •  <queue?  *— *  TSQ1' 


where  hTS  a  TS  A  TS*.  Note  that  Updat  eQ  specifies  that  the  named  queue  (alone)  is  updated 
but  does  not  specify  in  what  way  it  is  updated.  This  is  achieved  by  combining  it  with  the 
single  queue  operations  to  get  the  operation  on  named  queues. 

In  adding  named  queues  we  have  added  the  possibility  of  a  new  error  trying  to  perform 
operations  on  non-existent  queues.  This  error  is  given  by: 

NonEx  i  stent ! 

ATS 

queue"7  :  TSQName 
report!  :  CONDITION 


queue"7  t  dom(ts) 
TS*  =■  TS 

[  report!  3  QldErr 


Our  operations,  except  AppendQ  which  is  allowed  on  a  non-existent  queue,  can  now  be  redefined 
in  terms  of  our  previous  definitions: 

RemoveQ  a  (UpdateQ  A  Remove) \hTSQ  v  NonExi  stent! 

UriteQ  a  (UpdateQ  A  Urite)\ATSQ  v  Nonexistent! 

ReadQ  a  (UpdateQ  A  Read)\ATS0  v  NonExi stent! 

The  \ATSO  hides  the  temporary  variables  (ar .  p.  ar  ’  ,  p')  from  the  signature  of  the  final 

operation.  These  operations  ail  inherit  the  errors  from  the  equivalent  single  queue  operations. 


microcopy  resolution  test 

NAT'-'V.,  hllRIAI.  Of  SIANDABO.  , 


Temporary  Storage 


7 


A  queue  is  created  by  performing  an  AppendQ  operation  on  a  queue  that  does  not  yet  exist. 


The  following  schema  describes  the  creation  of  a  queue: 


Again  the  relationship  between  TSO_Initial  Car.  p)  and  TSQ'  Car*,  p' )  is  not  defined 
within  this  schema.  This  is  supplied  by  Append  in  the  following  definition: 

AppendQ  a  (CUpdateO  v  Created  A  Append )\ATSO 

Note  that  for  a  non-existent  queue,  if  an  error  occurs  at  the  Append  level  (ius.  a  No  Space 
condition),  then  an  empty  queue  will  be  created. 

In  addition  to  these  promoted  operations  on  named  queues  we  have  an  operation  to  delete  a 
named  queue: 


An  exception  occurs  if  the  queue  to  be  deleted  does  not  exist  so  the  definition  of  OeleteQ 
becomes: 

OeleteQ  a  OeleteQ,  v  NonExi stent! 


$ 

g 
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A  Network  of  Systems 


Temporary  storage  queues  may  be  located  on  more  than  one  system.  Let  us  call  the  set  of  all 
possible  system  identifiers  Sysid.  We  can  represent  temporary  storage  queues  on  a  network  of 
systems  by: 

NTS _ , 

I  nts  :  Sysid  -**  TS 


where  dom(nts)  is  the  set  of  systems  that  share  temporary  storage  queues  and  for  a  system 
with  identity  sysid  such  that  sysid  «  dom(nts),  nts(sysid)  is  the  temporary  storage  state  of 
that  system.  The  operations  on  temporary  storage  queues  may  be  promoted  to  operate  for  a 
network  of  systems  by  the  following  schema: 

Notuni-U 


ANTS 

sys i d? 

:  Sysid 

ATS 

sysid? 

«  dom(nts) 

TS  a  ntstsys 

d?) 

fits’  * 

nts  • 

<  sysid?  •-*  TS’  > 

where  ANTS  a  NTS  a  NTS*.  As  with  promoting  the  operations  to  work  on  named  queues 
above  schema  only  specifies  which  system  is  updated  but  not  how  it  is  updated.  This  will 
supplied  when  this  schema  is  combined  with  the  definitions  of  the  operations  on  a  single  syst 
Network  operation  also  introduces  the  possibility  of  an  error  if  the  given  system  does  not  exist: 

NoSy stem ! 


ANTS 

sysid? 

i  Sysid 

report 

:  CONDITION 

sysid? 

t  dom(nts) 

NTS’  » 

NTS 

report 

*  SysIdErr 

The  operations  on  a  multiple  system  are  given  by: 


AppendQN, 
RemoveQN, 
ReadON0 
Ur i teQN, 


a 

a 

a 

a 


(AppendQ  a  Network  3  VATS 
(RemoveO  a  Network  3 VATC 
(ReedO  a  Network 3 VATS 
(UriteO  a  Network  3  VATS 


v  NoSystem! 
v  NoSystem! 
v  NoSystem! 
v  NoSystem! 


k 


s 
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The  sysid7  and  queue7  name  supplied  as  inputs  are  not  necessarily  the  ones  on  which  an 
operation  takes  place.  A  queue  name  on  a  given  system  may  be  marked  as  actually  being 
located  on  another  (remote)  system,  possibly  with  a  different  name  on  that  remote  system.  We 
will  model  this  by  the  following  function  which  takes  the  input  pair  of  sysid7  and  queue7 
name  and  gives  the  corresponding  actual  sysid!  and  queue!  name  on  which  the  operation  will 
be  performed: 

remote  :  (Sysid  x  TSQName)  — *  (Sysid  x  TSQName) 

In  many  cases  the  input  sysid?  and  queue?  name  are  the  actual  system  and  queue  name;  in 
these  cases  remote  will  behave  as  the  identity. 

We  will  use  the  following  schema  to  incorporate  remote  into  the  operations: 

TSRemo  t »  | 

sysid?.  sysid!  :  Sysid 
queue?,  queue!  :  TSQName 


(sysid!.  queue!!  *  remotetsysid?.  queue?) 


The  outputs,  sysid!  and  queue!,  of  TSRemote  form  the  inputs  to  the  operations.  If  a  sysid? 
parameter  is  supplied  then  the  operations  on  temporary  storage  queues  are  defined  by: 

AppendQN,  a  TSRemote  >>  AppendQN, 

RemoveQN,  a  TSRemote  »  RemoveQN, 

ReadQN,  a  TSRemote  »  ReadQN, 

Ur.teQN,  a  TSRemote  »  UritaON, 


If  no  sysid?  parameter  is  given  then  the  operations  are  given  by: 

AppendQN,  a  AppendQN, Ccursysid?/sys id?) 

RemoveQN,  a  RemoveQN,Ccursysid?/sysid?l 
ReadQN,  a  ReadQN,  (cursysid?/systd?l 
UriteQN,  a  Ur  i  teQN,Ccursysi  d?/sysi  d?  J 

That  is,  the  sysid?  parameter  is  replaced  by  a  parameter  giving  the  identity  of  the  current 
system  (the  system  on  which  the  operation  was  initiated). 
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A  note  on  the  current  implementation 

Each  system  keeps  track  of  the  names  of  queues  that  are  located  on  other  (remote)  systems  and 
for  each  remote  queue  the  identity  of  the  remote  system  and  the  name  of  the  queue  on  that 
system.  It  is  possible  that  the  referred  request  could  be  for  a  queue  name  that  is  also  remote  to 
the  referred  system,  in  which  case  the  request  will  be  referred  on  to  yet  another  system.  To  find 
the  system  on  which  the  queue  actually  resides  we  need  to  follow  through  a  chain  of  systems 
until  we  get  to  a  system  on  which  the  queue  name  is  considered  locaL  We  can  model  the 
implementation  by  the  function: 

ram  :  (Sysid  x  TSOName)  -**  (Sysid  x  TSOName) 

which  for  a  sysid  and  queue  name  gives  the  sysid  and  queue  name  of  the  next  link  in  the  chain; 
if  a  sysid  and  queue  name  pair  is  not  in  the  domain  of  ram  then  the  chain  is  finished.  The 
correspondence  between  ram  and  remote  is  given  by: 

remote  *  rem* 

where  rem*  is  the  transitive  reflexive  closure  of  rem,  defined  by*, 
rem*  a  (id  \  dom  rem)  u  (rem*  •  rem) 


rem*(s»  q)  *  (s.  q)  if(s.q)<  dom  rem 

a  rem*  rem  (s.  q)  if  (s»  q)  «  dom  rem 

As  remote  is  a  total  function  the  equality  of  remote  and  ram*  requires  that  no  chain  of  rem 
contains  any  loop  (so  that  rem*  is  also  total). 

Given  the  function  rem  if  we  take  the  corresponding  (curried)  function  with  the  following 
shape: 

r  j  Sysid  — *  (TSONama  ■**  (Sysid  *  TSOName)) 

so  that: 

r (s) (q)  *  remts.  q) 

dom(r(s))  a  <  q  :  TSOName  I  (s»  q)  *  dom  rem  > 

The  mapping  that  needs  to  be  stored  on  a  system  s  is  given  by  r(s),  which  is  of  type: 

TSOName  -**  (Sysid  *  TSOName) 
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Abstract 


In  the  first  part  of  this  paper  we  show  how  to  construct  an  abstract 
specification  of  requirements  for  a  simple  assembler,  so  as  to  illustrate  a 
typical  way  of  using  the  language  of  set  theory  outlined  in(Sufrin84].  Both 
procedural  and  representational  abstraction  are  employed  in  order  to  capture 
the  essence  of  the  requirements  without  overwhelming  the  reader  with  details 
of  possible  implementations.  In  the  second  part  of  the  paper  we  give  the 
outline  of  a  high  level  design  for  a  program  and  indicate  how  to  prove  that 
it  is  a  realisation  of  the  requirements  formalised  in  the  first  part. 
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Introduction 

In  this  paper  we  first  show  how  to  use  the  language  of  set  theory  to  construct  a  simple 
formalisation  of  requirements  for  an  assembler,  then  we  outline  the  design  of  a  simple  "In-core** 
assembler,  show  that  this  design  meets  the  specification,  and  indicate  how  the  design  might  be 
further  developed  towards  an  implementation.  Both  specification  and  design  are  presented  at  a 
rather  abstract  level,  and  are  therefore  "unreal".  It  is  this  very  high  level  of  abstraction  which 
allows  the  specification  to  be  simply  explained  and  easily  understood,  and  allows  the  design  to 
be  easily  proven  to  meet  the  specification. 

An  Assembler  is  a  program  which  translates  a  sequence  of  "assembly  language  instructions”  into 
a  sequence  of  "machine  language  instructions”  ready  to  place  in  the  store  of  the  machine.  In 
this  paper  we  «haii  assume  that  the  machine  for  which  we  are  going  to  specify  our  assembler  is 
a  "one  and  a  half  address”  computer;  in  other  words  each  machine  instruction  will  reside  at  a 
certain  location  in  the  store  of  the  machine,  and  will  have  an  opcode  field,  a  register  field,  and 
an  address  field.  We  shall  also  assume  an  assembly  language  instruction  to  be  divided  into 
several  "fields*  —  an  optional  symbolic  label  field,  a  symbolic  opcode  field,  a  symbolic  register 
field,  and  a  symbolic  operand  field  Each  assembly  language  instruction  will  determine  the 
content  of  the  opcode  field,  the  content  of  the  register  field  and  the  content  of  the  address  field 
of  the  corresponding  computer  instruction.  Sometimes  the  opcode  field  will  contain  a  "directive” 
—  perhaps  indicating  that  the  radix  in  which  subsequent  numbers  are  to  be  interpreted  should 
change. 

In  order  to  simplify  what  follows  we  shall  consider  the  symbolic  opcode  and  register  fields  as 
one,  and  consider  the  machine  opcode  field  to  include  the  register  information.  A  typical 
translation  performed  by  the  assembler,  might  be 


Assem  blv  Language  Machine  Store 
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.  end 

1 

Primitive  Data  Types 

Applying  the  principle  of  representational  abstraction,  the  first  thing  that  we  decide  is  that  in 
order  to  characterise  an  assembly  language  instruction,  we  do  not  need  to  know  the  exact  details 
of  its  representation  as  a  sequence  of  characters  or  bit  strings.  By  the  same  principle,  neither  do 
we  need  to  know  the  exact  details  of  the  representation  of  a  machine  instructioa  We  will 
therefore  denote  the  entire  set  of  assembly  language  instructions  by: 
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A 

And  the  entire  set  of  machine  language  instructions  by 
t! 

The  essence  of  an  assembler  can  be  characterised  by  the  relationship  between  its  input  (a 
sequence  of  assembly  language  instructions)  and  its  output  (a  sequence  of  machine  language 
instructions).  We  will  find  it  far  easier  to  investigate  this  essence  if  for  the  time  being  we 
abstain  from  considering  things  like  error  listings,  and  relocateabie  binary  Hies.  This  is  not  to 
say  that  such  things  will  not  be  important  in  a  more  complete  specification  of  requirements,  but 
the  general  rubric  under  which  we  sail  is  "essence  first,  decorations  later1*. 

Formally,  then,  we  will  derive  a  relation  of  type 

seq  A  «-*■  seq  n 

The  next  step  in  our  formalisation  is  to  further  characterise  the  structure  of  the  assembly 
language  and  of  the  machine  language.  In  doing  so  we  shall  denote  the  set  of  (symbolic)  label 
identifiers  by 

SYM 

and  the  set  of  opcode  symbols  by 
OPSYM 

Structure  of  Instructions 

The  abstract  structure  of  assembly  language  instructions  can  now  be  formalised  by  the 
introduction  of  four  functions,  corresponding  to  the  fields  of  the  instruction  and  related  by  two 
axioms: 


lab: 

A 

SYM 

"  '  1 

op: 

A 

-**  OPSYM 

ref: 

A 

-*»  SYM 

nua: 

A 

-**  N 

doe 

ref 

n  doe  nua  ■ 

{) 

doe 

ref 

U  doe  nua  * 

A 

Taken  together,  these  formalise  the  fact  that  an  assembly  language  instruction  may  have  a  label, 
and  an  opcode  field,  and  must  have  a  reference  or  a  number  field,  but  not  both.  Now  in 
characterising  the  abstract  structure  of  the  language  we  do  not  care  whether  the  Number  in  the 
operand  Held  arose  from  the  interpretation  of  a  string  of  decimal  digits,  binary  digits,  or  unary 
digits,  so  that  is  has  been  possible  here  to  suppress  radix  directives.  Indeed  the  structure 
presented  here  assumes  the  suppresssion  of  all  directives. 

The  abstract  structure  of  machine  instructions  may  be  characterised  similarly:  assuming  that  the 
instruction  and  address  fields  of  such  instructions  are  represented  in  our  specification  by  natural 
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numbers,  we  have: 


- 1 

inat:  fl  -**  N 

addr :  M  -»  N 


A  machine  language  instruction  may  have  an  instruction  field,  and  must  have  an  address  field; 
this  allows  us  to  use  the  assembler  to  preload  numeric  or  symbolic  values. 

We  shall  assume  that  we  have  been  given  a  way  of  translating  symbolic  opcodes  to  numbers, 
that  is,  a  function 


- 1 

an**:  OPSYH  -*+  N 


The  set  of  valid  mnemonic  opcode  symbols  is  the  domain  of  this  function 

Part  I:  Requirements 

We  require  that  the  assembler  translate  symbolic  opcodes  to  their  corresponding  numeric 
opcodes,  translate  symbolic  addresses,  where  they  appear,  to  numbers  representing  the 
corresponding  address,  and  translate  numeric  fields  where  they  appear.  In  what  follows  we  shall 
derive  predicates  corresponding  to  each  of  these  requirements  in  turn. 

Symbol  Definitions 

Suppose  that  the  input  sequence  of  assembly  instructions  is  denoted  by: 
in:  eeq  A 

Exploiting  the  fact  that  a  sequence  is  just  a  special  kind  of  function  from  the  natural  numbers, 
we  note  that  the  composition: 

in  i  lab 

is  a  function  of  type 
N  -**  SYM 

which  maps  the  number  of  each  instruction  in  which  a  symbolic  label  is  defined,  to  the  label 
which  is  defined  there.  In  the  case  of  our  example  we  have: 

in  )  lab  *  (  1»— »V1  2>— ‘V2  3>— ' 'loop  9*-*exit  ) 

The  inverse  of  this  function  is  in  general  a  relation  which  maps  symbols  to  all  the  places  in  the 
input  where  they  appear  as  labels.  For  this  reason  we  define: 


eyabtab  *  (in  i  lab)'* 


s 


In  order  to  formalise  the  idea  that  there  should  be  no  multiply  defined  symbols,  we  require  that 
the  inverse  of  symbtab  be  a  function.  Remember  that  in  general  the  inverse  of  a  function  may 
be  a  one-to-many  relation;  requiring  that  it  be  a  function  is  the  same  as  requiring  that  it  map 
element  of  its  domain  to  just  one  element  of  its  range.  Later  we  will  be  able  to  give 
additional  justification  for  this  rather  obvious  requirement,  which  is  expressed  formally  by: 

symbtab  «  SYH  -**  N 

Symbolic  and  Numeric  References 

Once  more  exploiting  the  definition  of  sequences,  the  composition 

in  >  ref 

is  a  function  of  type 
N  -**  SYH 


which  maps  assembler  instruction  numbers  in  the  input  to  the  symbols  which  are  referenced  at 
those  instructions.  In  the  case  of  our  example  we  have: 

{  3i— *v2  5»-*vi  6*—»v2  7i-+exic  8*—*loop  ) 

The  term 

ran(  in  i  ref  ) 

denot-i  the  finite  set  of  symbols  which  are  referenced  in  the  input,  so  to  formalise  the 
requi  ment  that  all  symbols  which  are  referenced  by  assembly  language  instructions  are  defined 
in  the  nput,  we  write: 

ran(  in  I  ref  )  s  doe  symbtab 

The  function 

in  l  nun 

of  type 

N  -**  N 

likewise  maps  assembler  instruction  numbers  in  the  input  to  the  numbers  which  are  referenced 
by  those  instructions. 

Exercise  L  show  that  by  virtue  of  the  axioms  for  ref  and  nun  the  two  functions  we  have 
just  discussed  have  disjoint  domains. 

Opcode  References 

The  function 

in  i  op 

of  type 
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N  -**  OPSYM 

maps  assembler  instruction  numbers  to  the  opcode  symbols  which  are  referenced  by  them.  To 
formalise  the  requirement  that  all  referenced  opcode  symbols  be  valid  mnemonics,  we  write: 

ran(in  t  op)  s  do a  ana  a 


Address  Fields 

Suppose  that  the  output  sequence  of  machine  instructions  is  denoted  by 
out :  eeq  M 
then  the  function 

out  l  ad  dr  of  type  N  -**  N 

maps  machine  addresses  to  their  corresponding  address  fields.  We  want  the  address  field  of  the 
instruction  at  location  n  to  have  the  value  of  the  symbol  at 
(in  I  ref)  n 

if  assembler  instruction  n  had  a  symbolic  operand.  The  corresponding  value  is 
(in  I  ref  i  eymbtab)  n 
and  we  want  it  to  have  the  value 
(in  >  nua)  n 

if  the  corresponding  assembler  instruction  has  a  numeric  operand.  Since  every  assembler 
instruction  must  have  either  a  numeric  or  a  symbolic  operand,  we  can  express  this  formally  in  a 
single  line,  namely: 

(out  i  addr)  *  (in  i  ref  >  syabtab)  u  (in  j  nua) 

In  order  to  check  that  our  formalisation  is  sensible,  we  should  ensure  that  the  right  hand  side  of 
this  equality  denotes  a  function  (since  we  have  already  esublished  that  the  left  hand  side  does, 
so),  and  (because  we  have  staled  that  each  assembler  instruction  corresponds  to  a  single  machine 
instruction)  that  the  domain  of  this  function  is  the  same  as  the  domain  of  in.  Of  course  these 
needn’t  always  be  true,  but  the  conditions  under  which  they  are  true  will  be  the  preconditions 
for  a  successful  assembly. 

Let  us  first  examine  the  conditions  under  which  the  RHS  of  the  equality  denotes  a  function. 
Since  (exercise  1)  injraf  and  ininua  must  by  virtue  of  the  structure  of  the  assembly  language 
be  functions  with  disjoint  domains,  all  that  remains  necessary  for  us  to  articulate  explicitly  is 
that  eyabtah  itself  be  a  function;  this  condition  corresponds  to  the  "no  multiply  defined 
symbols"  condition  which  we  discussed  in  detail  earlier. 


10  Jui 


~  ■  *-*  '* 1  *-it  ■  •jli'J-.  ’j.  iLa 


^  V 


7 


•  N 


Next  we  examine  the  conditions  under  which  the  function  has  the  same  domain  as  in.  Since  the 
union  of  the  domains  of 

(in  i  ref)  and  (in  ;  nua) 

is  the  domain  of  in.  all  we  must  articulate  explicitly  is  the  condition  under  which  the  domain 
of 


(in  j  ref  ;  syabtab) 

is  no  smaller  than  the  domain  of  (in  t  ref).  This  is  precisely  when 
rant  in  J  ref)  S  do a  syabtab 

which  corresponds  to  the  "all  referenced  symbols  are  defined”  condition  discussed  earlier. 

Opcode  Fields 

All  that  remains  is  for  us  to  formalise  the  relationship  we  require  between  the  opcode  Helds  of 
the  input  and  the  instruction  Helds  of  the  output.  This  is  simply; 

out  i  inat  »  in  t  op  I  ansa 

Ensuring  that  every  assembler  instruction  with  an  opcode  Held  gives  rise  to  a  machine 
instruction  with  a  corresponding  Held  is  just  a  question  of  ensuring  that  the  domain  of  the 
right  hand  side  is  equal  to  the  domain  of  in  top.  This  is  ensured  providing  that  the  range  of 
in  top  is  a  subset  of  the  domain  of  ansa,  corresponding  to  the  "all  referenced  opcodes  must  be 
valid  mnemonics'  condition  discussed  above. 
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Soecification  Summa 


In  this  section  we  summarise  the  discussion  so  far  by  defining  the  relation 
we  wish  to  hold  between  the  inputs  and  outputs  of  the  assembler. 


Context: 


lab:  A  -**  SYH 

op:  A  -**  OPSYH 

raf :  A  *•*  SYH 

nua:  A  -**  H 

do  a  ref  n  do  a  nua  =  O 
do a  ref  U  doa  nua  =  A 


inat:  fl  -+♦  N 
addr:  M  — ►  N 


anea:  OPSYH 


Specification: 


aaaeableato:  oeq  A  *-*  aeq  H 


V  in:  aeq  A:  our:  aeq  (1  . 


ran(  in  »  ref  )  e  doa  ayabtab  A 

rant  in  I  op  )  s  doa  anea  A 

ayabtab  €  SYH  -**  N  A 

(out  i  addr)  *  (in  I  ref  I  ayabtab)  U  (in  >  nua)  A 
(out  i  inat)  =  (in  i  op  I  anea) 

where 

ayabtab  a  ( in  i  lab)'* 


Discussion 

We  have  illustrated  two  important  techniques,  namely  procedural  abstraction  and  representational 
abstraction,  by  formalising  the  essence  of  the  relationship  required  between  the  input  and  output 
of  a  simple  assembler.  By  procedural  abstraction  we  mean  statement  of  input-output 
relationships  without  statement  of  the  computational  structures  used  to  achieve  them;  by 
representational  abstraction  we  mean  the  statement  of  essential  structural  or  semantic  qualities  of 
data,  without  statement  of  the  computational  structures  used  to  store  them. 
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In  one  sense  we  might  be  said  to  have  established  the  basis  for  outlining  a  small  "theory”  of 
simple  assemblers.  Such  a  theory,  however  simple  and  abstract,  gives  us  an  intellectual  handle  by 
which  we  may  grasp  much  more  complicated  machine  and  assembly  languages,  such  as  those 
outlined  in  the  exercises  below. 

Any  program  which  can  be  proved  to  satisfy  the  relationship  defined  here  is,  for  us,  an 
assembler.  Now  we  haven't  given  any  clues  about  how  to  go  about  constructing  such  a 
program,  but  that  enterprise  is  the  subject  of  the  next  section  of  our  paper. 

Exercises 

2.  How  would  you  specify  the  appearance  of  a  listing  on  which  errors,  such  as  multiply  defined 
and  undefined  symbolic  references,  are  noted. 

1  What  should  the  output  sequence  of  instructions  look  like  for  erroneous  input?  Is  it 
important? 

4.  How  could  we  extend  the  specification  to  cover  radix  directives  in  the  input  language? 

5.  How  would  you  extend  the  specification  so  as  to  treat  register  symbols  properly. 

6.  Specify  an  assembler  for  a  V ax-like  machine,  whose  machine  instructions  don't  all  occupy  the 
same  number  of  addressable  units. 


Part  2:  High  Level  Design  of  an  In-Store  Assembler 

In  this  section  of  the  paper  we  outline  the  design  of  a  simple  in-core  assembler  and  show  that 
it  meets  the  specification  defined  above.  The  assembler  will  operate  in  two  phases:  during  the 
first  phase  it  will  build  a  symbol  table,  place  numeric  operands  and  opcodes  in  store,  and  build 
structures  which  represent  the  positions  of  symbolic  references;  in  the  second  phase  it  will  use 
the  symbol  uble  and  structure  reference  information  to  place  the  correct  values  in  the  remaining 
unfilled  address  fields. 

In  order  to  construct  a  model  of  a  two  phase  program,  we  will  need  to  define  three  things:  a 
set,  IS,  of  intermediate  states  (to  model  the  state  of  the  assembler  between  phases),  a  function, 
phaael,  to  model  the  first  phase,  and  a  function,  phaa»2,  to  model  the  second  phase.  In 
the  language  of  set  theory,  the  way  to  model  "first  this,  then  that"  is  to  compose  the  functions 
"this"  and  "that".  More  formally  we  aim  to  define 


IS 

phaeel:  aeq  A  •**  IS 
phaa«2:  IS  aaq  H 

In  order  to  prove  that  the  model  satisfies  the  specification,  we  will  have  to  prove  that  the 
composition  of  the  two  functions  has  at  least  the  same  domain  as  the  relation  assamblaoto, 
and,  moreover,  that  it  agrees  with  aaaaablaaco  on  its  domain.  More  formally 

doalphaaal  |  phasa2)  =  doa  aaaaablaato  * 

(phaaal  j  phaa*2)  S  aaaaablaoto 

We  call  this  relationship  "satisfies",  and  write: 
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phase 1  )  phaa«2  •  aaeeableato 


The  theory  of  "satisfaction’*  is  presented  in  Appendix  L  The  main  result  allows  us  to  give 
specif  cations  spec!  and  sp«c2  of  the  two  phases,  such  that 

spael  J  apae 2  s  aaaaableato 

knowing  that  if  we  can  find  phaaal  and  phasa2  such  that: 

phase 1  c  a peel  * 
phase2  s  apec2  A 
(ran  phaaal)  s  (do*  phaee2) 


then 


phaaal  )  phaae2  £  aaaaableato 


The  Design 

At  the  end  of  the  first  phase  we  shall  be  left  with  an  intermediate  state  in  which  information 
about  symbolic  definitions  (at),  and  information  about  symbolic  references  (rc)  is  available,  and 
in  which  there  is  a  sequence  of  partly-filled  machine  instructions  (anachronistically  but 
evocatively  called  core).  We  model  this  information  as  abstractly  as  possible  at  this  first  stage 
of  development.  More  formally. 


at:  SYH  «-*  N 
rt:  N  -«*  SYH 
core:  aaq  tl 


We  now  define  spael 


The  first  line  of  the  predicate  formalises  the  statement  that  the  symbol  table  records  all 
definitions  of  each  label.  The  second  line  formalises  the  statement  that  the  reference  table 
records  the  symbol  referenced  at  each  location  whose  assembly  instruction  had  a  symbolic 
operand.  The  third  line  formalises  the  statement  that  the  in-store  values  of  address  fields 
corresponding  to  locations  whose  assembly  instruction  had  numeric  operands  are  in  place.  The 
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fourth  line  formalises  the  statement  that  all  opcode  fields  are  in  place.  The  address  fields  of  the 
instructions  with  symbolic  operands  are  allowed,  by  this  specification,  to  take  any  values  at  all. 

The  second  phase  should  teave  all  opcode  fields  in  place,  should  leave  numeric  address  fields  in 
place,  and  should  "fix-up”  the  values  of  address  fields  corresponding  to  symbolic  operands. 
Since  the  "source  text'  is  no  longer  accessible,  the  only  way  to  tell  the  difference  between 
symbolic  and  numeric  address  fields  is  by  inspecting  the  domain  of  the  reference  table. 

Formally,  we  have: 


sp«c2:  IS  «■*  ssq  M 

i 

(at.  rt.  core)  aosc2  out  ** 

at  «  SYH  •**  N  a 

ran  rt  C  do a  st  a 

(out  j  inat)  *  (core  l 
(out  t  addr)  \  (doa  rt) 
(out  I  addr)  r  (doa  rt) 

inat)  a 

»  (core  )  addr)  \  (doa  rt)  a 
a  (rt  |  st) 

Exercise: 

Prove  that  the  composition  of  spacl  and  apsc2  satisfies  the  specification  aaasablsato. 

Conclusion 

We  have  constructed  specifications  for  the  two  phases  of  an  in-store  assembler.  In  each  case  we 
have  captured  the  essence  of  the  information  processed  by  the  phase,  but  in  neither  case  have  we 
specified  the  order  in  which  the  information  is  processed,  nor  have  we  specified  the  final  form 
in  which  this  information  will  be  stored  in  a  computer.  This  leaves  a  number  of  possibilities 
open  to  those  who  will  define  structurally  and  algorithmically  more  explicit  realisations  of  the 
two  phases. 

Appendix  1:  Satisfaction 

A  relation  r  is  said  to  satisfy  a  (relational)  specification  ■  if  its  domain  is  identical  to  that  of 
a  and  if  it  agrees  "pointwise*  with  s  for  each  element  of  their  common  domain. 


*  :  (X<-*Y)  «-*  (X«-*Y) 


r  *  s  «•  (do*  r)*(doa  s)  a  (r  s  s) 


For  example,  the  successor  function  on  the  natural  numbers  is  a  relation  which  satisfies  the 
specification:  "greater  than";  indeed  any  number  of  iterations  of  sue  satisfies  "greater  than". 

sue  <  *>"  V  n:N  .  nal  -•  sue"*  ’>" 

The  predecessor  function  on  the  natural  numbers  satisfies  the  specification  "less  than”,  but  may 


10  Jul  84 


12 


not  be  iterated  more  than  once  without  failing  to  satisfy  it 
pred  «  *<*  v  n:N  .  n>l  -•  “*>  < pred* *  *<*) 


The  first  two  results  are  rather  obvious:  satisfaction  is  both  reflexive  and  transitive, 
r:  X«-*Y  »-  r«r 

rl.  r2,  r3:  X«-»Y  *-  (rl«r2)  a  (r2*r3)  -*  Crl«r3) 

The  main  result  used  in  this  paper  concerns  the  relationship  between  specifications  and 
relational  composition. 

■1.  rl:  X  *-*  Y:  a2.  r2:  Y  «-*  Z 

h* 

rl*al  A  r2*a2  a  (ran  rllfildoa  r2)  «•  (rljr2)  *  (al>a2) 

These  results  allow  us,  when  searching  for  a  relation  which  satisfies  a  certain  specification,  to 
search  instead  for  two  relations  which  satisfy  the  specification  when  composed.  These  two 
relations  can  serve  in  turn  as  specifications  for  a  pair  of  relations  whose  composition  will 
satisfy  the  original  specification,  provided  that  the  second  implementation  relation  is  prepared  to 
"process*  everything  “output*  by  the  first. 

Acknowledgements 

The  author  has  benefited  from  much  discussion  over  the  years  with  colleagues  and  students  at 
the  Programming  Research  Group.  Jean-Raymond  Abriai,  who  first  showed  us  how  to  put  set 
theory  to  productive  use  as  a  Software  Engineering  tool,  remains  a  continuing  source  of 
inspiration  The  specification  is  a  much  altered  version  of  [Sorensen82];  any  mistakes  herein  are 
the  author's  own. 


Bibliography 


SorensenS2 


SufrinM 


Specification  of  a  Simple  Assembler 
QCS  Project  Working  Paper 
lb  Holm  Sorensen 

Oxford  University  Programming  Research  Group,  1982 


Mathematics  for  System  Specification 
Lecture  Notes  (MSc  in  Computation) 

Bernard  Sufrin 

Oxford  University  Programming  Research  Group,  1983/84 


10  Jul  84 


Casa  Studies 
m 

Formal  System  Spacit* ication 

Barnard  Sufrtn 
Oxford 

Hilary  1332/83 
Abstract  Algorithms 

Introduction 

The  correctness  criterion  for  our  simple  asssembler  was  a  relation  between  input  and 
output  m  which  we  used  functions  such  as  msersa  which  are  not  part  of  the  repertoire  of 
everyday  Cor  even  functional)  programming  languages.  We  used  these  functions  in  the 
specification  because  they  were  easy  to  raasan  mth;  as  we  develop  a  program  from  our 
specification  we  will  be  introducing  functions  and  structures  which  are  ever-closer  to 
those  provided  by  our  target  programming  language(s). 

In  the  case  of  the  assembler*  the  representational  abstraction  which  we  made  was  to 
model  the  input  and  output  as  sequences  of  abstract  objects  rather  than  characters*  and 
to  model  the  symbol  table  as  a  binary  relation  between  symbols  and  numbers-  The 
procedural  abstraction  we  made  was  to  specify  the  assembly  operation  by  using 
composition  on  entma  sequences  and  >  risers  ion .  In  a  later  section  of  the  course  we  will 
show  how  we  can  begin  to  use  more  machine-oriented  representations ;  in  this  section  we 
show  how  to  begin  to  use  machine-oriented  control— structures  in  the  realisation  of  what 
we  will  call  Abstract  Algorithms. 

As  our  first  example  we  take  the  problem  of  constructing  the  inverse  of  a  function  such 
as: 


step:  ST  —*  ST 

-e  -ant  to  choose  this  so  that  the  function 


INVALG  a  (repeat  step) 

satisfies  the  specification.  In  other  words  so  that 

INITIAL  S  do*  INVALG  a 
INVALG  t  INITIAL  J  C  FINAL 


Notes  have  included  a  small  appendix  m  uhtch  ue  define  the 
function  repeat  and  develop  a  small  mathematical  analogue  of  the 
theory  of  iterative  control  structures.  Although  the  rest  of  this 
document  is  relatively  independent  of  the  append tx ,  it  prav  ides  a 
more  formal  justification  for  some  of  the  informal  arguments  ue  use 
be lau . 

Design  of  Step 

Us  will  define  step  so  that  it  decreases  the  length  of  in  whilst  always  resulting  m  a 
state  which  is  m  the  set: 

INVAR  a  (  ST  |  rel*(so£ar  Jf)  where  so£ar  •  in  *  in0  ) 
our  definition  is.  • . 


Step  * 

irST  |  in*<> 
in’  3  tail  in; 
first  in  «  dos  £  -• 

rel'  *  rel  u  {  £«£irst  in  i+#in0-#in  > 
first  in  *  do*  f  -• 
rel'  =  rel 

.  .  .  which  can  be  proven  to  satisfy  the  above  requirements. 

Because  step  decreases  the  length  of  in,  and  maintains  the  INVARiant,  the  theory  of 
iteration  now  allows  us  to  conclude  that: 


(repeat  step)  «  (ST  — ►  ST) 

ran( repeat  step)  s  (  INVAR  h  (ST  -  do*  step)  ) 
Procedurally  interpreted  this  means  that  the  loop  terminates  in  state. 


(  ST  I  in=<>  >  r I  INVAR 


that  is- . . 


(  ST  |  in»<>;  rel=( sofar jf ) '*  where  sofar=inB  ) 

.  .  which  by  a  few  manipulations  transforms  to  FINAL. 


yv 


! 

g 

N 


Making  Step  less  Abstract 
The  specification  of  step  is  still  proceduraily  aostract  in  the  sense  that  it  involves  two 
mpiications : 


I 


& 

$ 


i 

i  > 

9 

5: 

"A 


first  in  •=  don 

first  m  *  doa  f  «  . . . 

Me  can  continue  the  process  of  algorithmic  development  by  splitting  step  into  tuo 
parts.  •  • 


change:  ST  -**  ST 

no  change:  ST  *♦*  ST 

wmch  are  defined  so  that 


step  =  (change  u  nochange) 
as  follows: 


change  = 

riST  j  in*<>:  first  in«(doa  £) 
in'  a  tail  in; 

rel'  a  rel  u  {  £[.o) first  in  *-*  l+#ina-#in  ) 
no change  = 

rtST  |  in#<>:  first  in* (doa  f) 
in’  a  tail  in; 
rel’  a  rel 

The  domains  of  these  functions  are  disjoint,  so  their  union  is  still  a  function.  Me  claim 
that  this  function  behaves  exactly  like  step,  leaving  the  proof  as  an  exercise- 

In  fact  taking  the  union  of  functions  with  disjoint  domains  is  the  closest  mathematical 
analogue  we  have  to  the  alternation  construct  of  programming  languages.  (Me  will  not 
here  consider  nondetarmimstic  alternation  of  the  kind  modelled  by  unions  of  functions 
with  nondisjomt  domains,  although  this  is  of  great  theoretical  and  practical  interest). 

So  far  we  have  convinced  ourselves  that  —  in  a  context  where  f  is  known  —  the  function 


(repeat  step) 

takes  us  from  an  initial  state  in  which  the  entire  input  sequence  remains  to  be  processed 
and  the  relation  is  empty,  to  one  in  which  there  is  no  input  left  to  be  processed  and  the 
relation  is  the  required  inverse. 


ft 

ft 


Me  can  achieve  this  initial  stats  by  a  function 


init:  seq(X)  — *  INITIAL 
init  ■ 

X  in„:  seqtX)  . 
uST  . 
rel=( ) ; 
inain. 

The  overall  structure  of  the  function  which  specifies  our  abstract  algorithm  is  now: 


3 


I 


nut  i  '  repeat  '  change  'J  nochange)) 

'he  "control  constructs"  used  have  seen  empnasised;  they  are  all  mathematical  functions. 

^>e  ">ow  ask  a  rhetorical  question:  s  it  possible  to  convince  ourselves  that  the  following 
program  mplements  the  aoove  abstract  algorithm'7 


let  in:seq£Xl  *  in, 
rel :  Y  ^  »  { )  in 
do 

i.n*<>  — * 

let  x:X  »  first  in 

n:  N  =  l*#ina-ein  in 
if 

xe(dos  f)  —* * 

rel.  in  •. »  rei  u  (  x»— >n  ).  tail  in 

a 

xi* (do*  £)  — * 

in  tail  in 
fi 
ad 

The  answer,  as  you've  probably  guessed,  is  supposed  to  be  ’yes'.  What  you  may  not  have 
guesed  is  just  hou  we  are  going  to  do  the  convincing. 

Uhat  we  shall  do  is  to  give  the  semantics  of  the  programming  language  in  terms  of  the 
mathematical  toois  with  which  we  are  already  familiar.  In  order  to  make  the  presentation 
simple,  we  will  not  give  a  formal  danotat/onal  semantics  —  a  mapping  from  phrases  of 
the  language  to  phrases  of  the  mathematical  toolkit;  instead  we  will  develop  the 
language  as  if  it  were  a  syntactic  sugaring  of  the  toolkit.  Once  we  have  done  this  it 
will  simply  be  obvious  that  the  program  and  the  algorithm  are  the  same  mathematical 
function  expressed  in  different  natations. 

By  showing  how  the  control  constructs  of  a  programming  language  can  be  modelled  by  the 
’algorithmic’  combmators  of  our  specification  language  we  hope  to  convince  the  reader 
that  "specifications’  and  "programs"  are  both  mathematical  objects,  subject  to 
mathematical  reasoning  methods,  and  that  there  is  no  unbridgeable  gulf  between  a 
procedurally-abstract  function  specification  and  a  program  which  computes  that  function. 


I 


*  * 
£ 


* 


$ 

£ 


The  Abstract  Algorithmic  Language 

In  this  section  we  define  the  Abstract  Algorithmic  Language  (AAL).  The  full  language 
is  not  implemented  anywhere;  it  is  merely  a  natation  which  allows  the  program  designer  to 
express  "procedurally"  strategies  for  computing  functions  (and  relations)  which  have  been 
specified  nonprocedurally. 

An  abstract  algorithm  is  just  a  partial  homogeneous  relation  (in  this  paper  we  will  only 
deal  with  deterministic  abstract  algorithms,  which  are  partial  homogeneous  functions).  As 
we  illustrated  earlier,  the  development  of  an  abstract  algorithm  starts  from  a 
procedurally-abstract  specification;  in  successive  steps  we  try  to  decompose  the  original 
specification  into  smaller  "more  computable’  specifications,  which  when  assembled  using 
the  "algorithmic"  combmators: 

U  alternation 

I  sequencing 

repeat  iteration 
t  guarding 

are  equivalent  to  the  original  specification. 
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Assignment 

Here  >s  one  of  the  simplest  of  the  aostract  algorithms: 


A  n :  N  .  a  *  n 

It  s  the  algorithm  winch  squares  its  single,  numeric,  variable.  Another  way  of  writing  it. 
which  makes  its  status  as  an  "algorithm*  a  little  clearer  is: 


it  n:iN  .  n'  3  n  *  n 

Another  way  of  writing  the  same  algorithm  is  provided  m  the  AAL  notation,  namely: 


prog  n:W  .  n  :*  n  x  n 
AAL  Programs 

In  general,  programs  m  AAL  have  the  form: 


prog  ...  v„:  T.  .  St 

where  Sc  is  an  AAL  Statement  in  which  the  variables  vl  . . .  vn  appear-  Ue  are  going  to 
explain  the  meaning  of  the  AAL  by  giving  the  syntax  of  each  kind  of  statement  and  then 
showing  what  partial  homogeneous  function  the  program 


prog  v,:!,  ...  v.:*.  •  St 

stands  for.  For  the  moment,  however,  we  will  continue  to  consider  the  meanings  of 
programs  of  just  one  variable  and  of  the  forms  by  which  such  programs  are  cobined  to 
produce  more  complex  programs:  later  we  will  give  the  rules  by  which  these  can  be 
generalised. 

Even  simple  assignment  programs  may  not  always  "work*:  for  example  consider  (program  1): 


prog  n:N  .  n  :*  n-1 
In  fact  this  is  the  function 


»  n:N  .  n'  *  n-1 

whose  domain  is  N-(0>.  If  we  give  a  procedural  interpretation  to  this  (that  is  to  say  if 
we  think  of  it  as  something  that  is  going  to  "run")  then  one  explanation  for  this  is  that 
program  1  does  not  terminate  for  all  possible  starting  states:  ar.  alternative  explanation 
is  to  say  that  this  program  is  going  to  cause  an  "exception”  to  occur  if  started  with  n=0. 

Let  us  consider  how  we  might  "totalise"  this  program.  ie  make  it  run  for  all  possible 
starting  values  of  n.  The  simplest  way  is  to  see  if  n  is  zero  and  in  that  case  do 
nothing  at  all.  The  hybrid  (because  expressed  m  a  mixture  of  the  AAL  and  mathematical 
notation)  relation  below  describes  just  this  behaviour: 

(prog  n:N  .  n  :•  n)  f  (  n:H  |  n*0  >  0 

(prog  n:N  .  n  :=  n-1) 

The  domains  of  its  two  component  functions  are  disjoint,  so  it  is  in  fact  a  function.  It 
maos  nonzero  n  to  n-1  and  maps  zero  to  zero. 

Ue  can  write  the  first  of  the  unioned  functions  in  a  more  compact  way  in  AAL  using  the 
"guarded"  form  of  statement. 


prog  n::N  .  rjsO  — *  n  :  =  n 

In  general,  t  Sc  s  an  APL  statement  and  ?  is  a  (mathematical)  predicate,  then  the  APL 
program : 


prog  x:X  .  P  — »  SC 
means  the  (now  hybrid)  function: 


(prog  x:X  .  SC)  r  (  x:X  |  P  > 

Even  if  we  use  this  new  notation  for  restriction,  our  function  is  still  expressed  m  hybrid 
form,  namely: 


(prog  n:N  .  n*0  — *  n  :a  n)  U 
(prog  n:N  .  n  :*  n-D 

Us  would  like  to  have  an  APL  form  for  taking  the  union  of  two  programs. 
In  general,  if  Scl  and  St2  are  APL  statements,  than  the  AAL  program: 


prog  x:  X  .  Sct  0  St, 
means  the  same  as  the  hybrid  program: 


(prog  x:  X  .  St4)  u  (prog  x:  X  .  St,) 

Sometimes,  to  make  it  clear  that  there  is  more  than  one  possible  "control  path”  within 
the  statement  Sc  we  will  write: 


if  St  fi 


This  means  the  same  as  St. 

How  do  we  say  "do  nothing7".  The  PPL  program: 


prog  X:  X  .  skip 

means  the  same  as  the  abstract  program 


that  is 


IT  x:  X  .  X'  =X 


(id  X) 


At  last  we  can  write  our  abstract  "exception  proof"  predecessor  program  entirely  in  APL. 
( program  2 )  : 


prog  n.-N  . 

.f 

n  :  *  n-  i 


Healthiness  of  Alternations 

If  «e  try  think  of  the  AAI_  notation  as  a  genuine  programming  language  then  we  notice 
something  rather  strange  about  program  2 ■  there  is  an  alternation  clause,  one  of  whose 
arms  s  not  "guaraed"  1  As  mathematicians  (at  least  temporarily)  this  doesn't  bother  us; 
aftar  all.  AAL  s  ,ust  a  notation  far  describing  mathematical  relations.  3ut  as 
.potentially)  implementers .  we  might  auake  in  our  boots  (or  foam  at  the  mouth)  at  the 
prospect  of  being  asked  to  implement  a  programming  language  with  assignments  m  which 
*railure”  of*  a  statement  causes  the  system  to  "backtrack*  to  the  last  Q  undoing  all 
assignments  an  the  nay  ' 

In  order  to  get  around  this  difficulty  we  shall  impose  a  healthiness  constraint  on 
alternation  statements.  The  ruie  will  be  that  all  statements  combined  mth  0  must  be 
guarded :  that  is.  alternatives  should  take  the  form: 


G 

G 

P„  -  Sc„ 

Moreover,  we  should  prove  for  each  of  the  guarded  statements. 
p,  “*  St, 

that  the  guard  is  stranger  than  the  "weakest  precondition*  of  the  statement.  / a 
(  x:  X  |  P,  >  S  doa(  prog  x:X  .  ST,  ) 

finally,  for  an  alternative  statement  to  be  "deterministic*,  the  "guard  sets*  must  be 
proven  to  be  disjoint  (this  is  a  sufficient  not  a  necessary  condition,  but  we  will 
voluntarily  burden  ourselves  with  it). 


Iteration 

If  St  is  an  AAl_  statement,  then  the  AAL  program: 


prog  x: X  .  do  St  od 
means  the  same  as  the  hybrid  program: 


repeat(  prog  x: X  .  St  ) 

Gur  theory  of  iteration  Cm  which  repeat  is  defined)  tells  us  that  if  we  are  to  prove 
anything  about  such  a  loop  then 


prog  x: X  .  St 

Had  better  denote  a  (strictly)  partial  decreasing  function. 

kn  general  then  the  Statement  of  a  loop  will  be  an  alternation  of  several  guarded 
statements,  for  example: 


7 


n  : =  n+ I 


prog  n:  N  . 
do 

n  <  3  — • 


fv 

3 

b 

n  >  4  — ►  n  :  =  n- 1 

od 

a 

;u.hicn.  no  matter  what  the  value  sf  n  has  originally,  leaves  it  either 
"termination" ) . 

3  or 

c 

o 

•i 

Sequencing 

If  Stl  and  St2  are  statements,  then  the  AAL  program: 

• 

\  » 
o  \ 

prog  x:  X  .  St,  :  St, 

*> 

means  the  hybrid  program: 

>  J* 

C  prog  x: X  .  St,  )  ;  (  prog  x:X  .  St,  ) 

V* 

v! 

Generalisation  to  Several  Variables 

for  the  most  part  the  generalisation  of  the  above  definitions  to  programs  of 

many 

ft 

variables  is  completely  straightforward.  The  only  exception  to  this  is  the 

assignment 

M* 

statement.  which  we  now  consider.  The  meaning  of  the  AAL  program: 

V 

fi 

Prog  v,:T,  ...  vb:T.  .  v  :*  E 

£ 

—  where  E  is  a  term  m  which  vl  .  . .  vn  appear  free  —  is  the  function: 

■ 

*  VT1  •••  Vf,  • 

•« 

» * 

v,1  =  v,i 

K 

0 

V  =  E; 

V/  3  V" 

r* 

S: 

In  other  words,  the  function  which  leaves  all  variables  unchar jod  except  for 

the  one  on 

u  » 

the  left-hand  side  of  the  assignment  sign. 

e? 

v; 

It  is  convenient  to  have  a  notation  for  simultaneous  assignment,  exemplified  by: 

$ 

prog  v,:T,  ...  v,:  T,  .  v.,  vjt  ...  v„  :*  E,,  E,.  ...  E, 

prog  V,:T,  ...  v„:T,  . 

v,  S,. 

\-4 

v  :  =  E  , 

y! 

j  a* 

n 

UJ 

II 

•  >m 

# 

It 

which  both  mean  the  function 

1% 

C\ 

b 

0 

i 


* 


ti 


r-: 


v,  = 

•//  =  E3; 

v.'  =  -v 
v,'  »  V, 

■"he  final  predicate  is  intended  to  convey  that  the  values  of  all  variables  other  than  vi 
vj  vk  remain  the  same. 

Notice  that  the  two  programs 

prog  a,b:-N  .  a  :=  b,  b  :  =  a 
prog  a,b:iN  .  a  :=  b:  b  :  =  a 

mean  different  functions;  the  first  means: 

X  a,b:N  .  Cb,  a) 
wm  1st  the  second  means: 


£ 


X  a.b:N  .  (b,  b) 


Assignment  to  Mappings 

In  the  same  spirit,  we  introduce  a  form  of  assignment  to  variables  of  a  special  type, 
namely  mappings.  Within  the  scape  of  a  variable 


M:  X  -**  Y 

ia  mapping  from  X  to  Y)  the  statement: 


fit,  =  £, 


means  the  same  as  the  statement: 


$ 

s; 


r.' 


H  :=*  ft  •  (  E,  ~  E,  > 

Naturally  the  terms  El  and  E2  had  better  be  well-typed ! 


Declarations 

Next  we  define  an  AAL  construct  which  introduces  "initialised*  variables-  If  St  is  a 
statement  and  E  is  a  term  of  type  Y  then  the  AAL  program: 


§ 


prog  x: X  . 

let  y: Y  *  E  in  St 


means  the  function 


Is 


(X  x: X  .  (x,  E))  I  (  prog  x:X;  y:Y  .  St  )  I  (X  x: X;  y:  Y  .  x) 
Similarly,  the  AAL  program 


3 


or og  x:  X  ■ 

let  v:  /  -  2,  and  z:2  =  2,  >n  3C 
-ears  tre  -''.ret: on 


A  x;  X  .  x.  2, .  2,)  ; 

.  prog  x:  X ;  v:Y:  z:2  ,  St  )  1 
x:  X;  y:  Y;  z:2  .  x) 

■n > s  concludes  our  definition  of  the  Abstract  Algorithmic  Language. 

Summary 

~e  tave  given  -ules  which  allow  AAL  "programs"  to  be  transformed  into  mathematical 
-eiations  (functions).  In  principle  it  is  enough  to  refer  the  person  who  wishes  to  reason 
aoout  AAL  programs  to  this  (albeit  only  semi-formal)  semantics,  and  suggest  that  any 

■easonmg  ae  pone  using  only  the  rules  of  mathematical  language.  In  practice  it  will  prove 
useful  to  derive  some  proof  rules  for  AAL  constructs  and  combining  forms  from  their 

mathematical  translations.  Indeed  the  constructs  we  have  described  so  far  were  chosen 
precsely  pecause  the  derived  proof  oiles  for  them  are  simple  to  understand  and  work 
->*th.  In  the  next  section  of  this  document  we  will  present  derived  proof  rules  for  AAL 
wpicn  will  be  familiar  to  students  of  OijUstra's  or  Hoare's  systems  of  reasoning  about 
programs,  "here  is  nothing  arbitrary  or  synthetic  about  the  rules  we  will  present,  they 

are  s.moly  consequences  of  (and  proved  using)  the  definitions  as  mathematical  fur~f:ons 

of  the  AAL  constructs. 
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1.  Definitions. 

LHS  a  RHS  Definition  by  syntactic  equivalence. 


2.  Logical  symbols. 


P  A  0 

p  v  Q 
P  —  <3 
'  P 
v 
3 


Conjunction:  "P  and  Q". 

Disjunction:  "P  or  Q“. 

Implication:  "P  implies  Q"  or  "if  P  then  Q". 
Negation:  "not  P". 

Universal  quantification:  "for  all  .  . 
Existential  quantification:  "there  exists  .  . 


3.  Sets. 


Set  membership 
Set  inclusion: 

Strict  set  inclusion: 


S  c  T 
Set 


(t  x:  S.  x  «  T)  . 
S  C  T  *  S  A  T. 


(sag  I  pred  .  csra)  The  set  of  ter®  such  that  pred  given  sag: 

x  ^  <  aig  I  prod  .  cera  )  C 3  aig  I  prad  .  x  -  Cara) 


u 

n 


Set  union: 

Set  intersection: 
Set  difference: 


S  u  T  a 
S  D  T  a 

s  -  r  a 


(  x:  X 
(  x:  X 
{  x:  X 


x  e  S  v  x  e  T  ) . 

X€SAX€T>. 

X6SA-X€T>, 


■ 

o 

The  empty  set 

( a.  b) 

Ordered  pair. 

Lv 

X 

Cartesian  produce 

X  »  Y  a  (  x:  Xi  y: 

P 

F 

a 


Power  sec  P  X  is  the  set  of  ail  subsets  of  X. 
Set  of  finite  subsets:  f  X  a  (  S:  P  X 

Size  (number  of  elements)  of  a  finite  set. 


S  is  finite  > . 


u.  n 


Generalised  set  union  and  intersection:  for  SS;  P  (P  X), 

U  SS  a  {  x:  X  I  (3  S:  SS  .  x  6  S)  >. 

n  SS  a  {  x:  X  I  (V  S:  SS  .  x  €  S)  ). 


dia -joint 


Pairwise  disjointness:  for  SS;  P  (P  X), 

disjoint  SS  a  Y  S,  T:  SS.  S  0  T  *  ( )  -»  S  *  T. 


4.  Relations  and  Functions. 


a  —  a 

A  —  B 


3)  . 


A  —•  3 


The  set  of  relations  from  AloB:  A  —  B  a  P(A 
The  set  of  partial  functions  from  A  to  3: 

A  -**  B  a  (  f ;  A  •—  B  I  (V  a:  A:  b.  b’ :  B  . 

a  £  b  A  a  f  b’  — b-b’)  ). 

The  set  of  total  functions  from  A  to  8: 

A  —  B  a  (  f:  A  B  I  (v  a:  A  .  3  b;  B  .  a  f  b)  >. 


b.  c 


.  .  j 


The  relation  (  a.  b).  ic,  d),  ...  >  relating  a  and  o.  c  and  d  .  .  . 
Lam  bda-abstraction: 

a  a:  A  I  prad  .  ears  a  <  a:  A  I  pred  .  (a,  ears)  > 

The  function  £  applied  to  x 

The  domain  of  a  relation  or  function:  for  R:  A  <-»  8, 
doa  R  a  {  a:  A  I  1 3  b:  8  .  a  R  b)  > . 

The  range  of  a  relation  or  function:  for  R:  A  •  B, 
ran  R  a  (  b:  B  I  C  3  a:  A  .  a  R  b)  > . 

Relational  or  functional  composition:  forR:  A  *-*  B ;  S:  B  *-»  C, 

S  •  R  a  {  a:  A:  c:  C  |  13  b:  B.  .  a  R  b  A  t  S  c)  ). 

Forward  relational  (or  functional)  composition:  R  i  S  a  s  •  R. 

Identity  function:  id  A  a  A  a:  A.  a. 

The  inverse  of  relation  R:  for  R:  A  «-*  B, 

R"'  a  <  b:  B;  a:  A  I  a  R  b  > . 

The  relation  (or  function)  £  composed  with  itself  k  times:  for  f:  A  *-*  A. 
£°  =  id  A.  f 1  =  £ ,  £*=£•£.  £J  =  £  •  f  •  £ .  ... 


K'- 


i 


(  )  Image:  for  R:  A  *-»B:  S=  P  A, 

R(S]  a  (  b:  B  I  (3  a:  S  .  a  R  b)  ) 

r  Domain  restriction  for  R:  a  *-*  B:  S:  P  A. 

R  r  S  a  (  a:  A;  b:  B  |  a  R  b  a  a  «  S  ). 

\  Domain  co-restriction:  R\S  a  R  r  ( A  —  S ) . 

J  Range  restriction:  for  R:  a  «■*  B:  T:  P  B. 

R  i  T  a  <  a:  A;  b:  B  I  a  R  b  a  b  «  T  >. 

/  Range  co-restriction:  R/T  *  RJ(B-T). 

•  Relational  or  functional  overriding:  for  £.  g:  A  «-»  B, 

£  •  g  a  ( £  \  doa  g)  U  g. 
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5.  Numbers. 


N 

9UCC 

a.  .  n 

maxi  a.  n) 


The  set  of  natural  numbers  (non-negative  integers) 
Successor  function:  aucc  a  a  n:  N  .  n*l. 

The  set  of  natural  numbers  between  a  and  n  inclusive 
a.  .  n  a  (  k:  N  |  a  <  k  <  n  > . 

The  greater  of  a  and  n 

a  >  n  -•  max!  a,  n)  *  a 
men  — »  maxi  a,  n)  =  n 


m 

|y  6.  Sequences. 


£ 

*»s 

aeq  A 

The  set  of  sequences  whose  elements  are 

drawn  from  A; 

seq  A  a  <  s:  N  -**  A  1  (3 

n:  N  .  doa  s  = 

»S 

The  length  of  sequence  s:  doa  a  si. 

.  #s. 

<  > 

The  empty  sequence  O. 

<a.  b.  c> 

The  sequence  (  1  ■—  a.  2  ►—  b,  3*—  c 

) .  etc.  . 

8 
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The  first  element  of  a  sequence. 

The  last  element  of  a  sequence. 

All  but  the  first  element  of  a  sequence. 

All  but  the  last  element  of  a  sequence. 

For  a:  seq  A  I  s  t  v> . 

head  a  a  a  ( 1 ) . 

last  s  a  sits), 

taxi  s  a  succ  ;  <s  \  ID) 

front  s  a  s  \  ! #s ) . 


Adding  new  head  and  tail:  for  s:  seq  A;  x:  A. 
x*s  a  (l^xlu  succ'1  i  s, 
s  *  x  a  a  u  (  succ  *s  ►  x  > .  • 


Concatenation;  <>#t=t.  (x*s)»t  =  x*(a»t), 
Reversing:  rev  <>  =  <>.  rev  (x  *  s)  =  (rev  s)  ‘  x. 


7.  Schema  Notation. 


[For  details  see  "Schemas  in  Z"]. 


Schema  definition: 


Use  in  signatures  after  »,  3,  A,  <  ...  > ,  etc.  : 

(  SCH  I  predicate  >  a  (  a;  A;  b:  8  I  axioms  a  predicate  >. 
v  SCH  .  predicate  a  v  a:  A;  b:  B  I  axioms  predicate. 


tuple 

pred 


The  tuple  formed  of  a  schema’s  variables;  tuple  SCH  a  (a.  b) 
The  predicate  part  of  a  schema;  pred  SCH  a  axioms. 


1  new/ old!  Renaming  of  components. 

S’  .  S,  Decoration;  systematic  renaming. 

Use  in  definition  of  other  schemas:  inclusion,  extension 


v,  etc.  Logical  operations. 


dora,  ran 
(  1 


Hiding. 

Projection 
Relative  consistency. 
Relational  composition. 
Domain  and  range. 
Application 
Overriding. 


